Present

Regrets

Chair

SV_MEETING_CHAIR

Scribe

TK

<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 dateTimeCanonicalMaphttps://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 durationhttps://www.w3.org/TR/xmlschema11-2/#duration

<brutzman> ...https://www.w3.org/TR/xmlschema11-2/#yearMonthDuration andhttps://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 Modelshttps://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.

Scribe.perl diagnostic output

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  Check for newer version athttp://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: TKFound ScribeNick: takiWARNING: No "Present: ... " found!Possibly Present: DB DP TK brutzman dape exi https joined scribeNick trackbotYou can indicate people for the Present list like this:        <dbooth> Present: dbooth jonathan mary        <dbooth> Present+ amyWARNING: No meeting chair found!You should specify the meeting chair like this:<dbooth> Chair: dboothFound Date: 26 Apr 2016Guessing minutes URL:http://www.w3.org/2016/04/26-exi-minutes.htmlPeople with action items: