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.

EXI4JSON

EXI for JSON - V2 change

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.

Canonical EXI

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.