See also: IRC log
TK: There is no telecon on
6/7.
... We will see if we have a telecon on 6/14 depending on the
topics available for discussion.
DP: I didn't manage to create a
proper schema.
... Suppose JSON map key has name "array".
... If we have separate namespaces, the issues don't
exist.
... By looking at the XML, we have an idea.
... In strict encoding, if we have wildcard, EXI jumps to a
global definition.
... We could prepend "_" to key names.
... In WoT discussion, key may have names that are not
permitted in XML.
... Name clash, and non-valid XML name. We need to address both
issues.
... We want to provide a solution for JSON-LD files. Things
like "sensor:unit".
<dape> {"my key": 123}
TK: ":" can be used in XML names if you disable namespace feature.
DP: Maybe we can upload several examples, to see the issues.
<brutzman> Perhaps another example or two would help. Show them in original XML, JSON EXI XML, and expected JSON result.
<brutzman> "Divide and conquer" approach rather than just working at a fairly abstract/schema level.
DP: Non-valid XML name issues, we didn't have the issue in the first draft. On the other hand, it didn't allow the use of schemas.
DB: Support for comments.
... We invented something for it.
... Because JSON does not have comments.
<brutzman> Reference: X3D to JSON Stylesheet, Design Correspondences, http://www.web3d.org/x3d/stylesheets/X3dToJson.html#DesignCorrespondences
<brutzman> "Comments are copied individually as JSON objects named #comment, interspersed with other -children nodes and ROUTEs. "
DP: We can support "#". ButOur goal is JSON -> XML -> JSON.
s/butOur/but our/
<brutzman> Where this can get tricky is avoiding overloading keys for the children of a given parent object. We accomplished that by only putting the #comment inside arrays.
<brutzman> This avoided the problem with non-unique keys, and preserved ordering of where comments occurred.
<brutzman> Importance: we need this capability to support XML -> JSON
DB: If we just want to compress JSON, maybe we don't need this.
DP: For JSON-to-XML, you don't have comments. When you start with XML, you start to need to worry about comments.
<brutzman> So the point is apropos, if the goal is solely to compress organic JSON, then this feature is not needed because such JSON has no comments. But if the original document is XML, or EXI for that matter, then the JSON representation will be lossy without such a mechanism.
DB: A lot of people uses comments.
<brutzman_> It is certainly possible to ignore the existence of comments, as Crockford did with JSON design.
<brutzman_> I prefer leaving such a choice to document authors. Thus there is some merit in including such a feature.
<brutzman_> Somewhat related: we might want to do a JSON Schema at some point to validate the resulting JSON from such a conversion.
<brutzman_> So there is probably some value in having a JSON Schema, but since the governing IETF RFC is a draft, it is not yet authoritative.
DP: JSON-schema currently is
draft 4.
... We should comment on it if we have one. But we are not the
right group to work on JSON-schema.
<brutzman_> So at this point it would be helpful for the tool chain, but not part of the EXI for JSON Editor's Draft.
<brutzman_> BTW, I tried to create a JSON Schema corresponding to the XML Schema in the Editor's Draft during this call.
<brutzman_> Was using XML Spy, new feature for XML Schema to JSON Schema (draft). Unfortunately it crashed! So I sent that company a trouble report.
DB: I am trying XML schema to JSON schema conversion.
<brutzman_> If they send back a fix, I will post it to the working group FYI.
<brutzman_> Altova JSON Schema Editor and Generator: http://www.altova.com/xmlspy/json-schema-editor.html
<brutzman_> Back to the key issue from before... Once we have some examples to look at further, and come up with our best response, it will deserve further public scrutiny.
DB: The change we made to the draft is small enough to wait longer.
<brutzman_> The changes in the Editor's draft seem small enough that we might wait a bit longer before posting an update... or is there any time pressure?
DP: The structure change we made was substantial. We can still wait.
CB: We also need more feedback.
<brutzman_> In support: the changes we are considering relate to implementation details, so we want to get focused feedback on our best recommendation. For people just interested in the capability, the principles are essentially the same.
DP: When people actually start creating schema, they will face it.
<brutzman_> Essentially we are fine-tuning mapping an XML schema to represent an arbitrary JSON structure.
<brutzman_> I think we are heading in the right direction... but prefer having examples that illustrate the issue we will ask for comment on.
<brutzman_> Having a draft JSON schema (if Altova can provide) would also provide further confirmation that our XML Schema in the EXI for JSON Editor's Draft is offering a good match for JSON.
DP: How to deal with schemaId
element. I sent the discussion result to public mailing
list.
... For schema-less and empty schemaId case, and schemaId have
value.
... For the first two cases, I suggested to explicitly include
schemaId.
<dape> https://lists.w3.org/Archives/Public/public-exi/2016Jun/0001.html
DP: The overhead of schemaId is minimal. Also it is good because it will allow later decode the stream.
<brutzman_> I posted a few more thoughts on this topic on the list: https://lists.w3.org/Archives/Public/public-exi/2016Jun/0002.html
<brutzman_> ... must go now unfortunately, thanks for another great and productive session today!
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/butOur/but our/ Succeeded: s/ones/one/ Succeeded: s/XML Schema and the/XML Schema in the/ No ScribeNick specified. Guessing ScribeNick: taki Inferring Scribes: taki WARNING: No "Present: ... " found! Possibly Present: CB DB DP Importance Reference TK brutzman brutzman_ dape exi https joined trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 02 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/02-exi-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]