<scribe> scribe: TK

<scribe> scribeNick: taki

EXI4JSON

https://lists.w3.org/Archives/Public/public-exi/2016Apr/0004.html

DP: I played a bit with transformation.
... We did encounter an issue. It was not possible to create a schema.
... In case of map, you had a problem.
... TK proposed one with property name becoming attribute name.
... key name now becomes an element name.
... compactness is a bit less efficient.
... generic schema is less restrictive.

TK: Is map definition the only change that was made?

DP: With the change, it becomes a bit less compact when generic schema is used.

<brutzman> DP walked us through the .zip attachment of examples using the possible alternative encoding

DB: The map can't be validated properly.
... This work might become influential.
... JSON developers have uneasy relationship with XML

<brutzman> JSON keys can include spaces. http://stackoverflow.com/questions/10311361/accessing-json-object-keys-having-spaces

<brutzman> As Daniel notes, this results in an invalid element name in the XML

<brutzman> I suspect that one use case will be someone creating the XML first and then converting to EXI and JSON. it will be frustrating if that isn't valid XML.

<brutzman> A major merit of the existing draft is that consistent validation is possible with a single EXI4JSON schema.

<brutzman> Another merit of the prior version is that it can validate key names that include strings

DB: We should try to do everything for validation.

<brutzman> My primary reaction is that we should support validation as far as we possibly can, so that content is correct and developers don't think that EXI4JSON is flawed.

<brutzman> The second approach also makes it a little bit harder to write converters, because element names are not consistent.

DB: This might make converter implementation harder.

<brutzman> The current EXI JSON intermediate XML schema also checks for key uniqueness, which is a good quality check during conversion.

<brutzman> We observed how, within a map, the order of contained information in the first approach is type-name-value.

<brutzman> In the second approach, the order is name-type-value.

<brutzman> This could be less efficient to process because knowing the type first allows more streamlined handling of the name and value.

<brutzman> DP: the second approach requires more buffering while processing.

<brutzman> DP: next step, hope someone comes up with an even better idea! 8)

<brutzman> I expect that the current approach is likely to appear best because of emphasis on XML validation. Anything that continues to strengthen XML schema validation will lead to reliable adoption.

<brutzman> Wondering if we should mention the second approach has been considered, and apparent pros/cons, as a way of inviting comment.

Canonical EXI

DP: Comments from TK, DB and JS

<brutzman> ... just sent a partial response to technical dialog

DP: DB seems to have some issues regarding datetime canonicalization.

<brutzman> datetime has been discussed a number of times before but we still have no strictness or canonicalization involved

<brutzman> ... as you note, this is also problematic for XML Signature since logically equivalent dates might not be consistent

<brutzman> ... most application use cases do not care about datetime format in a document, because application and user preferences control that.

<brutzman> ... (for example, what I18N/L10N language is used).

<brutzman> Suggested practice: when precise date format is important in a document, the format can be a separate attribute from the date value itself.

<brutzman> Picking a canonical date format also permits high-performance data parsing & validation, which is important. Many date formats are possible.

DP: Can we make that best practice?

DB: If we don't require, then it won't occur.

<brutzman> Adding an optional format can be a best practice, but canonical formatting of date itself needs to be a requirement.

<brutzman> One additional possibility is to add an EXI option that date values are handled as arbitrary strings without canonicalization.

DP: We heard use cases that need to preserve timezone.

<brutzman> timezone can be considered somewhat similar to format, perhaps handled the same way

<brutzman> https://www.w3.org/TR/xmlschema11-2/#dateTime

<brutzman> "dateTime uses the date/timeSevenPropertyModel, with no properties except ·timezoneOffset· permitted to be absent. The ·timezoneOffset· property remains ·optional·."

<brutzman> ... aha, here is dateTimeCanonicalMap https://www.w3.org/TR/xmlschema11-2/#vp-dateTimeCanRep

<brutzman> ... so why don't we simply require that form as canonical date, and create an EXI Option that allows relaxation of all dates to string

<brutzman> ... this approach means that Signature works, efficiency is supported, and developers can preserve formats if needed without modifying a document data model.

<brutzman> DP: discussing duration types

<brutzman> XML Schema (to the rescue, again) discusses duration types

<brutzman> ... 3.3.6 duration https://www.w3.org/TR/xmlschema11-2/#duration

<brutzman> ... https://www.w3.org/TR/xmlschema11-2/#yearMonthDuration and https://www.w3.org/TR/xmlschema11-2/#dayTimeDuration

<dape> ... https://www.w3.org/TR/xmlschema-2/#duration

<brutzman> discussion on timezone issues...

<brutzman> my expectation is that they had a similar discussion when designing XML schema; they kept timezone optional, in variable and canonical forms

<brutzman> concerned that if we don't decide on a canonical date, then EXI processors are at liberty to change date arbitrarily and signature isn't preserved

<brutzman> aha, dates themselves are only numeric, so performance is not an issue

<brutzman> Properties of Date/time Seven-property Models https://www.w3.org/TR/xmlschema11-2/#dt-dt-7PropMod

<brutzman> Summary for me today: preserving Signature validity is very important so please let's address this.

<brutzman> not sure what happened but webex disconnected my voice line! no more thinking together allowed today...

<brutzman> again thanks for great discussion, see you next time

DP: We should describe in the spec that canonical exi does not do anything about timezine, and timezone should be taken care of in application level.

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)

Succeeded: s/convert/converting/
Succeeded: s/qualiity/quality/
Found Scribe: TK
Found ScribeNick: taki

WARNING: No "Present: ... " found!
Possibly Present: DB DP TK brutzman dape exi https joined scribeNick trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 26 Apr 2016
Guessing minutes URL: http://www.w3.org/2016/04/26-exi-minutes.html
People with action items: