See also: IRC log
<scribe> scribe: TK
<scribe> scribeNick: taki
<dape> https://lists.w3.org/Archives/Member/member-exi-wg/2016Sep/0003.html
DP: In WoT document, we described using method #1.
DB: JSON schema community is
active, we can continue to use it in an informative
manner.
... There will be a formal standard.
<brutzman> Wondering if the example 23/24 that you are showing on the screen implies a different XML schema supporting EXI4JSON?
DP: More prose way to describe the JSON is possible.
<brutzman> so are you saying: availability of a JSON schema might show a more efficient to encode the JSON, which in turn might be more efficiently represented?
<brutzman> also wondering, does Taki's example show a general mapping from JSON schema to XML schema?
<brutzman> so perhaps 2 EXI4JSON mappings are possible: (a) XML schema for JSON types in EXI4JSON draft; (b) EXI schema, mapped to an XML schema, in turn used for an EXI encoding
<brutzman> correction
<brutzman> so perhaps 2 EXI4JSON mappings are possible: (a) XML schema for JSON types in EXI4JSON draft; (b) JSON schema v4, mapped to an XML schema, in turn used for an EXI encoding
<brutzman> revision #2
<brutzman> so perhaps 2 EXI4JSON mappings are possible: (a) XML schema for JSON types in EXI4JSON draft; (b) JSON schema v4, mapped to an XML schema using the mappings in WoT Practices, in turn used for an EXI encoding
<brutzman> Reference: WoT Current Practices Unofficial Draft 06 September 2016, 3.2.4.3 Mapping to XML Schema, http://w3c.github.io/wot/current-practices/wot-practices.html#mapping-to-xml-schema
<brutzman> Approach (b) matches the EDITOR'S NOTE there: A complete "JSON Schema" to "XML Schema" mapping needs to be defined.
<brutzman> So would you rather have approach (a) or (b)?
<brutzman> Yogi Berri: "when you come to a fork in the road - take it"
<brutzman> ... so in our case, we should explore both. Each will be very interesting and have pros/cons
<brutzman> Example: Pros for approach (a) includes simplicity, repeatability, etc.
DB: Approach A is good at
simplicity.
... Approach B can be more efficient.
<brutzman> If Approach (b) can be more more efficient, it might be preferred however.
<caribou> approach b) would be more interesting only if you already have a JSON schema instance, right?
<caribou> it depends on whether JSON schema is widely used...
<brutzman> It might also be the case that Approach (b) is more compact, but Approach (a) has better performance. Testing will be needed./
DP: I think the efficiency will
be the same.
... Approach A is more generic. Without JSON schema, it
works.
... Approach B requires JSON schema.
<brutzman> It is further interesting that JSON Schema will be present for many things, and this pair of approaches will be possible will be possible for anyone to choose from.
<brutzman> If the goal is to round-trip convert JSON to JSON, then Approach (b) is more involved. Interoperability might be considered less as well.
<brutzman> Since both approaches are possible, it seems appealing to add another section to EXI4JSON draft showing Approach (b) - adapting & completing the writeup in WoT Best Practices
<brutzman> ... subsequent comparison of test results will also be helpful to characterize there
<brutzman> DP: will work on it to see if that is a good direction
<brutzman> Not to be overlooked: given any JSON, which is an inherently well-formed object, there is at least one and possibly 2 ways to map it to XML Schema and to EXI.
<brutzman> ... in other words, it appears that XML Schema is a superset of what can be expressed in JSON
<brutzman> Approach (a) seems analogous to well-formed data with type awareness, while approach (b) supports schema validation structures
DB: Approach A is anologous to well-formed type-aware approach.
<brutzman> Another interesting point is that Approach (a) is suitable for hardware implementation
DB: Approach A is suitable for hardware implementation.
<brutzman> Also worth noting: for round trip JSON to JSON, both approaches are lossless
DB: Are both approach A and B loss-less?
DP: Yes
<brutzman> There are some interesting parallels. In some ways, the question "Is XML Schema needed for your data" is similar to "Is JSON Schema needed for your data"
DP: I did minor tweaking. No big
changes.
... I would like to ask the group for a final review.
CB: I can help in adapting it to use new style.
TK: Please review it for
Candidate Recommendation publication.
... Can we make publication decision next week?
<brutzman> I am still concerned with Issue 114 https://www.w3.org/2005/06/tracker/exi/issues/114
<brutzman> This seems contrary to have 4 alternatives. The notion of utcTime is inherent to the XML schema of the governing document, which is clearly stated in the XML Schema recommendation. With/without options ought to be simple: they are there, or they are not. So I don't understand why 4 varieties are expressed.
<dape> https://lists.w3.org/Archives/Public/public-exi/2016Jul/0000.html
<brutzman> I could see that an EXI Option might express utcTime normalization status - but that is optional. If it is a required part of the canonicalization encoding, then that is forcing the canonicalizer to make a semantic declaration regarding something that is not known.
<brutzman> Is Issue 114 still viable, or overcome by events?
<brutzman> So is this the resolution: https://www.w3.org/XML/EXI/docs/canonical/canonical-exi.html#utcTime
<brutzman> ... [Definition: The utcTime option is used to specify whether Date-Time values must be represented using Coordinated Universal Time (UTC, sometimes called "Greenwich Mean Time"). ]
<brutzman> DP: 2.1 Canonical EXI Options, https://www.w3.org/XML/EXI/docs/canonical/canonical-exi.html#canonicalOptions
<brutzman> Thanks! That is where I had hoped you landed.
<brutzman> Are all open Issues and Actions handled? https://www.w3.org/2005/06/tracker/exi/products/14
<brutzman> discussion - most can be closed, TK will update and close them after the call
<brutzman> DP: some tests and other small issues remain, they can occur after this next draft
<brutzman> it seems valuable to publish in time for TPAC
<brutzman> ... because that will help support any discussions with XML Security group, which is important for our future strategies to achieve compatible EXI security
<brutzman> DP thinks it would be good if EXI group can all check again
<brutzman> Since the editors draft is already available, I suppose that is satisfactory preparation for TPAC.
<brutzman> TK: also wants to perform another thorough review
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) Found Scribe: TK Found ScribeNick: taki Present: TK DB DP CB WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 06 Sep 2016 Guessing minutes URL: http://www.w3.org/2016/09/06-exi-minutes.html People with action items:[End of scribe.perl diagnostic output]