Efficient XML Interchange Working Group Teleconference

06 Sep 2016

See also: IRC log




<scribe> scribe: TK

<scribe> scribeNick: taki


ACTION-739: Integrate WoT type system's schema mapping content into EXI4JSON spec

<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, 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"

Canonical EXI

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

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/09/06 15:33:50 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]