Efficient XML Interchange Working Group Teleconference -- 23 Feb 2016

<scribe> scribe: TK

<scribe> scribeNick: taki

EXI for JSON

DP: Do you seriously think key name as attribute name is a good solution? For example, JSON key name can be any string.

TK: I would be glad to use alternative solutions if it doesn't have that problem. But I also think being able to describe the document using EXI grammar is also important.
... And the issue does not become evident unless you try to serialize it into text XML.

DP: I did see Don's post to GitHub.
... Somebody replied mentioning CBOR. Is there any progress on this in general?

DB: There is an issue list. It will stabilize in the next draft.

DP: I just subscribed to the issues list. It might take some time.

<caribou> CBOR is IETF work

DB: If we do tests at some point, we have to show results are close, faster.
... There will be an ecology of these tools.

DP: EXI for JSON is efficient representation of JSON. So is CBOR.
... CBOR could also use type information in schema.

<brutzman> RFC 7049, Concise Binary Object Representation (CBOR) https://tools.ietf.org/html/rfc7049

DB: It looks like CBOR is intended for more general use.

DP: Introduction and Objectives doesn't mention "JSON" until objective #6.

<brutzman> The CBOR objectives are interesting to compare to EXI.

<brutzman> The similarities in data types appear to be identical, on first glance.

DP: Stephen Williams also suggested to take a look at BSON.
... I am not sure if there are much need to convert between CBOR and EXI for JSON.
... With EXI for JSON, one can use the same implementation for EXI as well as EXI for JSON.

<brutzman> I am wondering if a future draft of EXI for JSON we ought to consider writing up a comparison of features, capabilities and constraints with CBOR and other JSON compression schemes.

DB: CBOR spec says CBOR must be able to decode without schema.

DP: If we use EXI for JSON, we currently don't require schema.

DB: On the other hand, I don't think they forbid the use of schema.

DP: In EXI, there are use cases that requires the use of schema, other use cases don't.

<brutzman> Wondering, if you have an arbitrary EXI document that uses a schema-informed compression, is the XML schema required for decoding?

<caribou> iirc, CBOR was originally designed by IETF CoAp folks, they also use EXI for XML based exchange

DP: MPEG also has binary XML. BiM allows the exchange of schema information upfront. It was not very successful.

DB: EXI may or may not require use of schema.
... ... depending on the use of feature "schemaId"

DP: If the schemaId is null, there is no schema knowledge.

DB: But there are still string lookup table.

<brutzman> DP: an EXI may or may not require use of XML schema, depending on whether schemaID is defined or not...

<brutzman> It would be interesting to see what differences might exist in a result document, depending on presence of schema during decoding.

DP: You can define some schema with types that are never used.

<brutzman> If there are some cases where decoding of an EXI -> XML is ambiguous or impossible without the original schema, they might be worth looking at.

DP: Then, you can decode with/without schema.

<brutzman> This feature can be useful for streaming, but there are other use cases too. Perhaps there should be an option for an EXI document to be standalone.

DP: Nobody forces you to use schema.

DB: Then, schema-less documents cannot be decoded using schema-informed decoder.

<brutzman> The trouble with going schema-less on a schema-informed XML vocabulary is that the resulting EXI document would not be compatibly decoded.

DP: We do have schema-less, schema-informed.

<brutzman> Perhaps there might be an whereby an EXI document could be encoded in a schema-informed fashion, but was also capable of being decoded without a schema.

DP: When schemaId is "" (empty string), it is minimal schema. It just have schema datatypes.

<brutzman> Of note is that the decoded XML document is simply element-attribute-value with no expression of data types in the output.

DB: We can explicitly type data in encoded streams.

<brutzman> I suspect there is a use case here: encoding in a schema-informed fashion for maximum compression and compatibility, yet able to be decoded correctly as XML without the schema... perhaps too specialized a use case though.

DB: Have we discussed about schema compression?

DP: We discussed it two years ago at TPAC about grammar representation.

<brutzman> Possibly another related area: have there been many examples of compressing the XML schemas themselves, in order to support reduced-memory and higher-performance for EXI use on limited devices?

DP: BiM exchanged schema knowledge upfront. BiM has representation of schema.

<brutzman> It would seem that a compressed XML schema is unambiguous and removes the need for some alternate form of grammar compression.

<brutzman> Tradeoff with XML schema compression: might contain more information than is needed, but it only has to be sent once.

DP: Compressed XML schema requires schema processor. Grammar representation doen't require that.
... Also, we can support multiple schema languages.

DB: You can process uncompressed XML schema.

DP: Yes, but it has downside.

<brutzman> However a schema can be used to create an EXI grammar. So it might be an interesting feature in an implementation. This would be a good path to explore, because then we would likely know if a compressed grammar representation for EXI is worthwhile.

DP: I did some experiments. Dedicated grammar format is much more efficient.

<brutzman> Certainly if we had an XML schema that described EXI grammars, any grammar documents that were written out in XML might be EXI compressed.

<brutzman> That of course must be simpler than schema parsing per se.

<brutzman> Wondering if EXI grammar representation in XML is listed as a candidate feature for EXI 2.0? That would appear to have some value for small devices. The existence of the CBOR objective for schema-free decoding is thus interesting and well expressed.

<brutzman> It is possible that the original discussion about representing an EXI grammar seemed rather abstract, but now there appears to be a use case.

<brutzman> If the EXI grammar representation is described via an XML schema, and XML constructs matching the EXI Recommendation, then it would seem that any EXI engine could parse the grammar and utilize it internally.

<brutzman> Perhaps a pair of use cases exists for various uses: EXI-compressed schemas, and an XML schema for an EXI grammar.

DP: For example, JSON format schema information is better for JSON implementation.
... It is doable to define one common representation. But in practice it is difficult.

<brutzman> I would hope that we can look at both XML Schema compression (e.g. what EXI options are preferred) and EXI grammar representation (for supporting mobile devices without schema support) in EXI 2.0.

<brutzman> There was mention of Grammar Exchange Format in prior meeting minutes

<brutzman> https://lists.w3.org/Archives/Member/member-exi-wg/2014Jun/0022.html

<brutzman> Issue 111 BSON support is similar to our CBOR discussion today https://www.w3.org/2005/06/tracker/exi/issues/111

<brutzman> Perhaps we should create a new one to consider new section on JSON Compression Considerations (or somesuch) in next EXI for JSON; include comparisons and tradeoffs associated with CBOR, BSON, etc.

<brutzman> I think if we drafted such a section, it would quickly be apparent if it added value to EXI for JSON

<brutzman> Am not proposing new features, just that a simple overview comparison for comprehension is likely of interest.

<brutzman> That would help readers decide what is best tool for the job

<brutzman> ... and also help us ensure that we had considered all objectives of interest relative to EXI for JSON and EXI itself.

<brutzman> Entered as ACTION-735: Compare EXI for JSON with other JSON compression schemes

<brutzman> https://www.w3.org/2005/06/tracker/exi/actions/735

<brutzman> next, considering a possible ACTION: did either of the previous proposals on grammar exchange format consider creation of an XML schema describing an EXI grammar?

<brutzman> ... am thinking that describing an EXI grammar from the perspective of the EXI Recommendation is a better starting point. ("Starting from scratch" if you will.)

<brutzman> It might then be easier to determine (a) does it accurately express an EXI grammar, and (b) does it meet the necessary goals of the original proposals?

<brutzman> This approach would seem to be able to avoid any implementation-specific biases. It would also help support use case of limited-memory mobile devices with schema-informed grammars.

<brutzman> Perhaps for today it is simply enough to list "XML schema for EXI grammar representation" as a candidate goal for EXI 2.0.

<brutzman> Entered in EXI 2.0 as New Feature: EXI Grammar Description https://www.w3.org/XML/EXI/wiki/EXI2#.28New_Feature.29_EXI_Grammar_Description

<brutzman> We also agreed to review Actions and Issues during the next meeting

- DRAFT -

Efficient XML Interchange Working Group Teleconference

23 Feb 2016

Attendees

Contents

EXI for JSON

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output