Efficient XML Interchange Working Group Teleconference

03 May 2016

See also: IRC log




<scribe> Scribe: TK

<scribe> ScribeNick: taki


EXI for JSON structure

TK: Using xsi:type, the number of wildcards would reduce.

DP: We can limit the subtypes.

TK: I will experiment with encoding, and get some numbers.

Canonical EXI

DP: Acknowledgement section also needs discussion.

CB: CSS WG, if you sent one bug, you get acknowledged.
... I had looked at the public list, and checked who contributed to canonical EXI by commenting.
... I think I got all of them.

DP: We currently only have five external people.

CB: It is a matter of preference.

TK: Why not list all of them?


DB: Three primary things. Plus editorial comments.
... Canonicalization of dates, URIs and range of floats.
... If we don't have canonicalization, we don't have canonical document.
... XML schema provides default.

DP: In our original proposal, we had datetime canonicalization.
... We got feedback from JS, saying there are use cases that do not want it.
... We saw the point. We decided that we don't do. Application should do it.
... Now both DB and JS (in his last comments) think we should do it.
... We can introduce another option that tells how datetimes will be canonicalized.
... We can also use similar methods as EXI profile, using EXI options.

DB: User agents re-sign the documents. Without canonicalization, it becomes a problem.

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

<brutzman> For unadorned dates, we might simply say that schema default is used as EXI default for canonicalization

DB: In XML schema, for date, it defines default form.

<brutzman> ... for special forms, authors can either use a separate format string or

<brutzman> ... use an EXI option to relax date canonicalization and indicate that dates should be treated as scheme

<brutzman> I think that XML Schema is quite deliberate in stating that timeZoneOffset is optional because many systems and data documents have no concept of timeZone

<brutzman> ... so <utc> is too specialized as an option

DP: Would we want URI? or a new header option?

DB: It may not be possible to do datetime canonicalization. This is a problem.

<brutzman> I think we must completely avoid any directions from EXI regarding timeZoneOffset because that relates to information that is not necessarily present in the document

<brutzman> Simplest: respect data type. If schema says xs:date then follow that. Alternative: relax date form to string.

<brutzman> Thanks for pointing out on the screenshot that Schema also says, iff a timezone is present, then it is normalized to UTC. Completely agree that we should match XML Schema normalization.

<brutzman> confusion about schema versions... W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes is 5 April 2012

<brutzman> XML 1.1 dateTimeCanonicalMap https://www.w3.org/TR/xmlschema11-2/#vp-dateTimeCanRep

<brutzman> ... which provides 2 forms, depending on whether timeZone value is present or not

<caribou> http://www.w3.org/TR/xmlschema11-2/#rf-explicitTimezone

<brutzman> ... timezoneCanonicalFragmentMap https://www.w3.org/TR/xmlschema11-2/#f-tzCanFragMap says 'z'

<caribou> http://www.w3.org/TR/xmlschema11-2/#dateTime

<brutzman> ... although not clear that it says convert to 'z' in https://www.w3.org/TR/xmlschema11-2/#f-tzCanFragMap

<caribou> "Note: Order and equality are essentially the same for dateTime in this version of this specification as they were in version 1.0. However, since values now distinguish time zone offsets, equal values with different �timezoneOffset�s are not identical, and values with extreme �timezoneOffset�s may no longer be equal to any value with a smaller �timezoneOffset�."

<caribou> (so canonical form when there's no timezone is the same)

<brutzman> FWIW related, 2.2.2 Equality says "For another example, the dateTime datatype previously lost any time-zone offset information in the ·lexical representation· as the value was converted to ·UTC·; now the time zone offset is retained and two values representing the same "moment in time" but with different remembered time zone offsets are now equal but not identical."

<brutzman> If we align with the proper XML Schema reference (whatever that is!) then we should be OK.

<brutzman> Possible relaxation option: a schema might use dateTime with timeZone, which would thus require normalization to UTC 'z' -- but a document author might want dates to remain unmodified. So providing an EXI option that indicated "treat date types as strings" or perhaps "do not canonicalize dates" would support the document author.

<brutzman> DP: can use Preserve.lexicalValues option set to true for this case

<brutzman> ...sounds good to me, avoiding new options

DP: We need to define how to specify it.
... We need another URL that indicates "without datetime normalization".
... I will propose a naming.
... I think we can also use just numbers.
... I will also propose this to the mailing list.
... Also letters may be good.

DB: In the third option, you can remove "and" from the URL.
... I think human readability is good.
... Like "OptionA"
... We can just use lexical preservation.
... Why do we need an option to disable datetime normalization?

<brutzman> This is a slippery slope... if we just have token to indicate Preserve.lexicalValues off, that is simple and straightforward

<brutzman> ... note that a document might have some dateTime values with time zone, and other dateTime values without timeZone, so applying a special option just regarding timeZone might become very confusing.

<brutzman> ... i suggest the two most sensible choices are either XML Schema-based dateTime normalization, or treating all dateTime values as strings.

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/05/03 15:42:04 $

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)

Succeeded: s/DP/DB/
Found Scribe: TK
Found ScribeNick: taki

WARNING: No "Present: ... " found!
Possibly Present: CB DB DP ScribeNick Simplest TK brutzman caribou exi https joined 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: 03 May 2016
Guessing minutes URL: http://www.w3.org/2016/05/03-exi-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]