15:01:10 RRSAgent has joined #exi 15:01:10 logging to http://www.w3.org/2016/01/19-exi-irc 15:01:12 RRSAgent, make logs public 15:01:12 Zakim has joined #exi 15:01:14 Zakim, this will be EXIWG 15:01:14 I do not see a conference matching that name scheduled within the next hour, trackbot 15:01:15 Meeting: Efficient XML Interchange Working Group Teleconference 15:01:15 Date: 19 January 2016 15:04:00 dape has joined #exi 15:05:17 scribe: TK 15:05:24 scribeNick: taki 15:06:05 TOPIC: EXI for JSON 15:10:24 brutzman has joined #exi 15:11:47 quick review of the responses in that mail 15:14:43 DP: strict and schemaId is set. Other options can be configurable. 15:15:12 DB: compression is off by default. 15:16:02 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. 15:16:40 DB: Is there EXI use case without compression? 15:16:43 DP: Yes. 15:17:13 DP: You can do a lot better than JSON without compression. 15:17:34 DP: Car charging use case also uses EXI without compression. 15:18:22 OK it is useful...however what do we think is minimum support capabiltity for conformance/interoperabilty? Does that need to be defined? 15:18:36 DP: Also, when communication channel is compressed already, EXI does not need to do its compression. 15:20:30 I suppose another good use use - perhaps a generalization of the one that you gave - is potential use of uncompressed EXI by IoT devices 15:22:13 DB: Is it satisfctory that some implementation does not support compression, for example? 15:22:34 s/satisfctory/satisfactory/ 15:22:48 DP: EXI specifications allows for that. 15:24:13 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." 15:25:30 That is likely a common question for users of this encoding, so we ought to point them in the correct direction. 15:26:24 aha, 3rd paragraph: 5.4 EXI Options 15:26:40 "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." 15:30:51 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 15:31:25 Similar comparisons would be useful when wireless communications were added to the IoT use case. 15:32:56 Such a comparison is likely to be influential not just for software adoption but possibly even for hardware design. 15:33:58 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. 15:34:56 Comparison parameters include compaction and performance, which in turn includes memory consumption and computational load 15:36:59 DP: also distinguish memory for code footprint from memory for buffering, they are different 15:37:57 ... returning to discussion of email comments 15:40:04 DP: We simply defined schema, and two options that are set. 15:40:13 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." 15:41:23 s/EXI options/EXI Options/ 15:41:57 DP: EXI options can be absent. 15:44:43 the quoted statements are hopefully sufficient to describe interoperability 15:45:28 DB: Can we discuss versioning next? 15:47:30 DB: It is 2016. Changes are possible. My concern is we are missing versioning. 15:48:31 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 15:48:40 DP: Having version numbers is good. In the next EXI for JSON, we can use a new number. 15:51:18 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 15:52:58 DP: summarized implicit "version 1" style described in email 15:54:11 we can use /ns/exi-for-json-1/ later if we decide to have versioning on the final note 15:55:14 CB: We can later decide whether we use versions or not. 15:56:10 CB: Versioning is not that significant for WD. 15:56:46 s/WD/work not on Rec Track, i.e. non normative/ 15:59:15 It is appropriate to describe the versioning mechanism in the document, so that potential future modifications are understood. 16:01:26 For example: "If future versions of EXI for JSON are specified, version identification will be reflected in the schemaID value." 16:03:02 s/will be/are/ 16:03:40 oops, how about "If future versions of EXI for JSON are specified, version identification is reflected in the schemaID value." 16:05:13 DP: I would add one sentence to say those two options cannot be changed. 16:07:39 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. 16:14:09 Summary of 3 statements: 16:14:10 "Negotiation of what options need to be supported by an EXI for JSON implementation are handled externally to the document." 16:15:55 DP: 2. "Both EXI Options for strict and schemaID are REQUIRED." 16:16:45 DP: 2. "Both EXI Options for strict and schemaID are REQUIRED and cannot be changed." 16:17:40 3. "If future versions of EXI for JSON are specified, version identification is reflected in the schemaID value." 16:19:01 ... continuing 16:19:14 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."" 16:20:28 DB: Encoding assumes information model, and it is about how to apply that. 16:20:54 DB: I do not think we need to make a statement in the spec about this. 16:22:51 I don't think we need to make the Editorial note in section C.2 but it is OK if you want feedback 16:23:00 DP: no feedback needed 16:23:33 DB: xs: double issue. 16:24:41 DP: At risk it is in EXI for JSON. 16:25:37 DP: Currently we can represent number as decimal. Decimal is not giving you a lot of benefits. 16:26:14 DB: Can we paraphrase it like "decimal support may not be necessary."? 16:26:40 ... yes, the words "at risk" are not clear 16:27:27 The working group considers the xsd:decimal support may not be necessary. 16:28:22 I think the discussion was very helpful today. With those changes, I think the WD is ready for publication and subsequent comment. 16:28:50 TK: Do we want to publish the document after Daniel incorporates the changes we discussed in this call? 16:28:54 DB: Yes. 16:30:18 RESOLUTION: We publish EXI for JSON document after we incorporate the changes and the minor changes pointed out by Javier 16:34:18 DB: Javier's work on RDF, and I am curious what he has done so far. 16:34:30 DP: Definitely, I am too. 16:35:37 rrsagent, create minutes 16:35:37 I have made the request to generate http://www.w3.org/2016/01/19-exi-minutes.html taki 16:35:54 taki has left #exi 17:03:21 Zakim has left #exi