Efficient XML Interchange Working Group Teleconference

EXI for JSON

<brutzman> quick review of the responses in that mail

DP: strict and schemaId is set. Other options can be configurable.

DB: compression is off by default.

DP: It is off by default in EXI. Compression is a bit of a burden for some applications. More buffering, memory, etc. I would keep default value.

DB: Is there EXI use case without compression?

DP: Yes.
... You can do a lot better than JSON without compression.
... Car charging use case also uses EXI without compression.

<brutzman> OK it is useful...however what do we think is minimum support capabiltity for conformance/interoperabilty? Does that need to be defined?

DP: Also, when communication channel is compressed already, EXI does not need to do its compression.

<brutzman> I suppose another good use use - perhaps a generalization of the one that you gave - is potential use of uncompressed EXI by IoT devices

DB: Is it satisfactory that some implementation does not support compression, for example?

DP: EXI specifications allows for that.

<brutzman> Perhaps we should add a sentence or two to Concepts section, e.g. "Negotiation of what options need to be supported by an EXI for JSON implementation are handled externally to the document."

<brutzman> That is likely a common question for users of this encoding, so we ought to point them in the correct direction.

<brutzman> aha, 3rd paragraph: 5.4 EXI Options

<brutzman> "EXI processors MAY provide external means for applications or users to specify EXI Options when the EXI Options document is absent. Such EXI processors are typically used in controlled systems where the knowledge about the effective EXI Options is shared prior to the exchange of EXI streams. The mechanisms to communicate out-of-band EXI Options and their representation are implementation dependent."

<brutzman> Future issue: it would be interesting to compare computation load (proportional to power consumption) for JSON, uncompressed EXI for JSON, and compressed EXI for JSON, when used by IoT devices on a common network

<brutzman> Similar comparisons would be useful when wireless communications were added to the IoT use case.

<brutzman> Such a comparison is likely to be influential not just for software adoption but possibly even for hardware design.

DP: CBOR, BSON etc. They do not seem to support compression. Memory requirements is an issue. In EXI, you can switch between compressed vs non-compressed.

<brutzman> Comparison parameters include compaction and performance, which in turn includes memory consumption and computational load

<brutzman> DP: also distinguish memory for code footprint from memory for buffering, they are different

<brutzman> ... returning to discussion of email comments

DP: We simply defined schema, and two options that are set.

<brutzman> and so, a summary of interoperability issues: "Interoperabilty by EXI for JSON implementations is achieved by agreeing to support the EXI Options utilized in documents that are shared."

DP: EXI options can be absent.

<brutzman> the quoted statements are hopefully sufficient to describe interoperability

DB: Can we discuss versioning next?
... It is 2016. Changes are possible. My concern is we are missing versioning.

<brutzman> Summary: 2015 -> 2016 to match document with no corpus to maintain; "draft" since some changes might occur during review; version number to allow future modifications without difficulty

DP: Having version numbers is good. In the next EXI for JSON, we can use a new number.

<brutzman> Example of a versioning problem: we publish some example EXI for JSON documents now; changes occur during Working Draft review; the initial examples are no longer correct, but nevertheless have the same identifying header

<brutzman> DP: summarized implicit "version 1" style described in email

<caribou> we can use /ns/exi-for-json-1/ later if we decide to have versioning on the final note

CB: We can later decide whether we use versions or not.
... Versioning is not that significant for work not on Rec Track, i.e. non normative.

<brutzman> It is appropriate to describe the versioning mechanism in the document, so that potential future modifications are understood.

<brutzman> For example: "If future versions of EXI for JSON are specified, version identification are reflected in the schemaID value."

<brutzman> oops, how about "If future versions of EXI for JSON are specified, version identification is reflected in the schemaID value."

DP: I would add one sentence to say those two options cannot be changed.

<brutzman> Including some form of the 3 sentences I typed above seem sufficient to remove the Editorial Notes. I am agreeable either way regarding inclusion of version "1" in the initial schemaID.

<brutzman> Summary of 3 statements:

<brutzman> "Negotiation of what options need to be supported by an EXI for JSON implementation are handled externally to the document."

<brutzman> DP: 2. "Both EXI Options for strict and schemaID are REQUIRED."

<brutzman> DP: 2. "Both EXI Options for strict and schemaID are REQUIRED and cannot be changed."

<brutzman> 3. "If future versions of EXI for JSON are specified, version identification is reflected in the schemaID value."

<brutzman> ... continuing

<brutzman> i liked your sentence ""If possible without loss of correctness, processors are recommended to use the default UTF-8 for maximum interoperability when creating JSON documents.""

DB: Encoding assumes information model, and it is about how to apply that.
... I do not think we need to make a statement in the spec about this.

<brutzman> I don't think we need to make the Editorial note in section C.2 but it is OK if you want feedback

<brutzman> DP: no feedback needed

DB: xs: double issue.

DP: At risk it is in EXI for JSON.
... Currently we can represent number as decimal. Decimal is not giving you a lot of benefits.

DB: Can we paraphrase it like "decimal support may not be necessary."?

<brutzman> ... yes, the words "at risk" are not clear

<dape> The working group considers the xsd:decimal support may not be necessary.

<brutzman> I think the discussion was very helpful today. With those changes, I think the WD is ready for publication and subsequent comment.

TK: Do we want to publish the document after Daniel incorporates the changes we discussed in this call?

DB: Yes.

RESOLUTION: We publish EXI for JSON document after we incorporate the changes and the minor changes pointed out by Javier

DB: Javier's work on RDF, and I am curious what he has done so far.

DP: Definitely, I am too.