<scribe> scribe: TK

<scribe> scribeNick: taki

TK: I may not be able to join the telecon next week. Let me confirm my schedule and let you know in a day or two.

EXI for JSON

DP: We have three different implementation. Java, JavaScript and C version.

TK: When I googled "EXI for JSON", editors draft comes at the top.

<brutzman> me too... but the document includes "Latest version" link which works

DB: You might want to report to the pub team.

DP: I will ask Carine to forward our request.

EXI for JSON structure

DP: I also played a bit with the JSON structure.
... I ran into the same issue I had before.
... Most XML schema processors would have problems.

TK: Current EXI spec does not support handling Duplicate Terminal Symbols with different types.

DP: In your example, both "manager" and "subordinate" are string, that causes an issue.

TK: With the current EXI for JSON structure, EXI spec section "Eliminating Duplicate Terminal Symbols" does not work.

DP: Either way, we have problems when we try to define XML schema.
... DB worried if the proposed structure permits querying.

<brutzman> There was some excellent dialog captured in meeting minutes from last week.

<brutzman> https://www.w3.org/2016/02/02-exi-minutes.html

<brutzman> Incidentally it would be helpful for the entire list if minutes might be posted after each meeting, and perhaps a link provided in agendas.

<brutzman> Regarding the current JSON encoding, it has a major virtue of being able to handle any JSON document correctly.

<brutzman> In some sense, if you solely use JSON itself, there is no further meta-information to take advantage of when trying to make an EXI JSON encoding as efficient as possible.

<brutzman> This is similar to using EXI with XML documents that do not have an XML schema.

<brutzman> So a key insight is that use of a JSON schema might allow a more "tuned" application of EXI algorithms.

<brutzman> That would then lead us to consider a pair of approaches to JSON compression: document based (no schema) or informed by JSON schema.

DP: With schema, if you can encode successfully, you know that your document is valid. Without schema, it is not possible.

TK: I will also check what update we will need in EXI spec for handling grammars with current EXI for JSON structure.

<brutzman> A potential path forward thus presents itself: comparison of expressive power between XML Schema and JSON Schema, anticipating possibly improved EXI encodings for JSON.

<brutzman> This approach might also raise suggested commonality that best supports the design of XML and JSON data structures with equivalent information models.

<brutzman> If we get that far, we will have gone a long way towards understanding whether bidirectional mappings between XML, EXI and JSON are feasible.

<brutzman> It will also illustrate the differences and tradeoffs between a strict object model (e.g. JSON)and a less-strict document model (e.g. XML PSVI).

<brutzman> s/(e.g.) /(e.g. JSON) /

<brutzman> Examples of document-model differences: unique keys, ordering of values, handling of comments, CDATA text blocks, and other XML-unique constructs.

<brutzman> I suppose such an effort might also inform JSON Schema (which is not yet standardized).

<brutzman> An interesting example might be generating JSON Schema from XML Schema, and vice versa, to see what can be captured and what is lost.

DP: I looked at JSON schema page. It was already 3rd or 4th version.

DB: We can reach out to them. Everything appears to have stopped.
... It exists, and there are products supporting that.
... It has great expressive power. Analogous to XML schema.

<brutzman> More information about JSON Schema is found at http://json-schema.org

DP: Map in JSON is not ordered. XSD "all" is not that powerful to support that.

DB: Differences will lead to design guideline.

<brutzman> The differences might lead to design guidelines for vocabulary authors; they might also lead to improvements in JSON Schema draft.

DP: XSD "all" is limited to maxOccurs="1".

DB: I have GitHub an account.
... JSON schema site appear to use GitHub for their mailing list.
... I would make an announcement.

<brutzman> We currently have interesting discussions about whether usage of JSON Schema for EXI JSON might lead to similar improvements in compaction and performance when using XML Schema with EXI. Further dialog will always be welcome.

<brutzman> ... that was draft sentence, added to announcement

<brutzman> subsequent to review of draft prose, we will post a full announcement to the JSON Schema group (issues/167 link above)

Canonical EXI

DP: What to do with empty elements, we decided in favor of one way.
... I will update the spec in this regard, just by removing one option that we did not take to choose.

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)

Succeeded: s/(e.g.) /(e.g. JSON)/
FAILED: s/(e.g.) /(e.g. JSON) /
Found Scribe: TK
Found ScribeNick: taki

WARNING: No "Present: ... " found!
Possibly Present: DB DP TK brutzman dape exi https joined scribeNick 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: 09 Feb 2016
Guessing minutes URL: http://www.w3.org/2016/02/09-exi-minutes.html
People with action items: