14:04:28 RRSAgent has joined #exi 14:04:28 logging to http://www.w3.org/2016/05/03-exi-irc 14:04:30 RRSAgent, make logs public 14:04:30 Zakim has joined #exi 14:04:32 Zakim, this will be EXIWG 14:04:32 ok, trackbot 14:04:33 Meeting: Efficient XML Interchange Working Group Teleconference 14:04:33 Date: 03 May 2016 14:04:36 zakim, this is exi 14:04:37 got it, taki 14:11:43 Scribe: TK 14:11:47 ScribeNick: taki 14:12:10 TOPIC: EXI4JSON 14:12:23 TOPIC: EXI for JSON structure 14:13:41 TK: Using xsi:type, the number of wildcards would reduce. 14:15:23 DP: We can limit the subtypes. 14:22:23 TK: I will experiment with encoding, and get some numbers. 14:22:50 TOPIC: Canonical EXI 14:23:35 DP: Acknowledgement section also needs discussion. 14:24:46 CB: CSS WG, if you sent one bug, you get acknowledged. 14:25:59 CB: I had looked at the public list, and checked who contributed to canonical EXI by commenting. 14:26:18 CB: I think I got all of them. 14:26:38 brutzman has joined #exi 14:30:43 DP: We currently only have five external people. 14:31:38 CB: It is a matter of preference. 14:31:50 TK: Why not list all of them? 14:33:16 https://lists.w3.org/Archives/Public/public-exi/2016Apr/0008.html 14:33:48 DB: Three primary things. Plus editorial comments. 14:34:11 DB: Canonicalization of dates, URIs and range of floats. 14:34:39 DB: If we don't have canonicalization, we don't have canonical document. 14:34:59 DB: XML schema provides default. 14:35:30 DP: In our original proposal, we had datetime canonicalization. 14:35:49 DP: We got feedback from JS, saying there are use cases that do not want it. 14:36:17 DP: We saw the point. We decided that we don't do. Application should do it. 14:36:50 DP: Now both DB and JS (in his last comments) think we should do it. 14:37:41 DP: We can introduce another option that tells how datetimes will be canonicalized. 14:38:50 DP: We can also use similar methods as EXI profile, using EXI options. 14:39:57 DP: User agents re-sign the documents. Without canonicalization, it becomes a problem. 14:41:13 s/DP/DB/ 14:43:34 XML Schema dateTime https://www.w3.org/TR/xmlschema11-2/#dateTime 14:44:05 For unadorned dates, we might simply say that schema default is used as EXI default for canonicalization 14:44:11 DB: In XML schema, for date, it defines default form. 14:44:29 ... for special forms, authors can either use a separate format string or 14:45:15 ... use an EXI option to relax date canonicalization and indicate that dates should be treated as scheme 14:47:19 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 14:47:35 ... so is too specialized as an option 14:48:00 DP: Would we want URI? or a new header option? 14:50:01 DB: It may not be possible to do datetime canonicalization. This is a problem. 14:50:50 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 14:51:36 Simplest: respect data type. If schema says xs:date then follow that. Alternative: relax date form to string. 14:55:06 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. 14:59:17 confusion about schema versions... W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes is 5 April 2012 15:01:00 XML 1.1 dateTimeCanonicalMap https://www.w3.org/TR/xmlschema11-2/#vp-dateTimeCanRep 15:01:43 ... which provides 2 forms, depending on whether timeZone value is present or not 15:02:34 http://www.w3.org/TR/xmlschema11-2/#rf-explicitTimezone 15:03:07 ... timezoneCanonicalFragmentMap https://www.w3.org/TR/xmlschema11-2/#f-tzCanFragMap says 'z' 15:03:33 http://www.w3.org/TR/xmlschema11-2/#dateTime 15:04:14 ... although not clear that it says convert to 'z' in https://www.w3.org/TR/xmlschema11-2/#f-tzCanFragMap 15:04:56 "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·." 15:05:25 (so canonical form when there's no timezone is the same) 15:06:28 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." 15:07:11 If we align with the proper XML Schema reference (whatever that is!) then we should be OK. 15:10:27 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. 15:11:15 DP: can use Preserve.lexicalValues option set to true for this case 15:12:05 ...sounds good to me, avoiding new options 15:15:13 DP: We need to define how to specify it. 15:16:28 DP: We need another URL that indicates "without datetime normalization". 15:19:28 DP: I will propose a naming. 15:26:14 DP: I think we can also use just numbers. 15:26:30 DP: I will also propose this to the mailing list. 15:26:53 DP: Also letters may be good. 15:28:04 DB: In the third option, you can remove "and" from the URL. 15:28:41 DB: I think human readability is good. 15:29:13 DB: Like "OptionA" 15:30:37 DB: We can just use lexical preservation. 15:30:54 DB: Why do we need an option to disable datetime normalization? 15:31:51 This is a slippery slope... if we just have token to indicate Preserve.lexicalValues off, that is simple and straightforward 15:33:10 ... 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. 15:34:15 ... i suggest the two most sensible choices are either XML Schema-based dateTime normalization, or treating all dateTime values as strings. 15:41:59 rrsagent, create minutes 15:41:59 I have made the request to generate http://www.w3.org/2016/05/03-exi-minutes.html taki 15:42:01 sorry to drop off prematurely! finally realized that when i close the webex window, it is also disconnecting me from the telconm 16:16:59 Zakim has left #exi