14:00:44 RRSAgent has joined #exi 14:00:44 logging to http://www.w3.org/2016/04/26-exi-irc 14:00:46 RRSAgent, make logs public 14:00:46 Zakim has joined #exi 14:00:48 Zakim, this will be EXIWG 14:00:48 ok, trackbot 14:00:49 Meeting: Efficient XML Interchange Working Group Teleconference 14:00:49 Date: 26 April 2016 14:00:53 zakim, this is exi 14:00:53 got it, taki 14:03:31 dape has joined #exi 14:10:21 brutzman has joined #exi 14:12:57 scribe: TK 14:13:03 scribeNick: taki 14:14:50 TOPIC: EXI4JSON 14:14:58 https://lists.w3.org/Archives/Public/public-exi/2016Apr/0004.html 14:15:29 DP: I played a bit with transformation. 14:15:47 DP: We did encounter an issue. It was not possible to create a schema. 14:16:09 DP: In case of map, you had a problem. 14:16:32 DP: TK proposed one with property name becoming attribute name. 14:17:10 DP: key name now becomes an element name. 14:17:55 DP: compactness is a bit less efficient. 14:18:10 DP: generic schema is less restrictive. 14:19:33 TK: Is map definition the only change that was made? 14:25:15 DP: With the change, it becomes a bit less compact when generic schema is used. 14:25:37 DP walked us through the .zip attachment of examples using the possible alternative encoding 14:26:34 DB: The map can't be validated properly. 14:27:38 DB: This work might become influential. 14:27:56 DB: JSON developers have uneasy relationship with XML 14:30:56 JSON keys can include spaces. http://stackoverflow.com/questions/10311361/accessing-json-object-keys-having-spaces 14:31:17 As Daniel notes, this results in an invalid element name in the XML 14:33:21 I suspect that one use case will be someone creating the XML first and then convert to EXI and JSON. it will be frustrating if that isn't valid XML. 14:33:35 s/convert/converting/ 14:35:08 A major merit of the existing draft is that consistent validation is possible with a single EXI4JSON schema. 14:35:25 Another merit of the prior version is that it can validate key names that include strings 14:36:03 DB: We should try to do everything for validation. 14:36:53 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. 14:39:23 The second approach also makes it a little bit harder to write converters, because element names are not consistent. 14:39:25 DB: This might make converter implementation harder. 14:40:17 The current EXI JSON intermediate XML schema also checks for key uniqueness, which is a good qualiity check during conversion. 14:40:46 s/qualiity/quality/ 14:42:48 We observed how, within a map, the order of contained information in the first approach is type-name-value. 14:43:09 In the second approach, the order is name-type-value. 14:43:42 This could be less efficient to process because knowing the type first allows more streamlined handling of the name and value. 14:44:49 DP: the second approach requires more buffering while processing. 14:49:33 DP: next step, hope someone comes up with an even better idea! 8) 14:51:01 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. 14:53:23 Wondering if we should mention the second approach has been considered, and apparent pros/cons, as a way of inviting comment. 14:57:00 TOPIC: Canonical EXI 14:57:41 DP: Comments from TK, DB and JS 15:01:04 ... just sent a partial response to technical dialog 15:01:22 DP: DB seems to have some issues regarding datetime canonicalization. 15:01:56 datetime has been discussed a number of times before but we still have no strictness or canonicalization involved 15:02:38 ... as you note, this is also problematic for XML Signature since logically equivalent dates might not be consistent 15:03:27 ... most application use cases do not care about datetime format in a document, because application and user preferences control that. 15:04:03 ... (for example, what I18N/L10N language is used). 15:04:57 Suggested practice: when precise date format is important in a document, the format can be a separate attribute from the date value itself. 15:05:43 Picking a canonical date format also permits high-performance data parsing & validation, which is important. Many date formats are possible. 15:06:01 DP: Can we make that best practice? 15:06:15 DB: If we don't require, then it won't occur. 15:06:44 Adding an optional format can be a best practice, but canonical formatting of date itself needs to be a requirement. 15:07:40 One additional possibility is to add an EXI option that date values are handled as arbitrary strings without canonicalization. 15:08:10 DP: We heard use cases that need to preserve timezone. 15:08:54 timezone can be considered somewhat similar to format, perhaps handled the same way 15:10:03 https://www.w3.org/TR/xmlschema11-2/#dateTime 15:10:35 "dateTime uses the date/timeSevenPropertyModel, with no properties except ·timezoneOffset· permitted to be absent. The ·timezoneOffset· property remains ·optional·." 15:11:49 ... aha, here is dateTimeCanonicalMap https://www.w3.org/TR/xmlschema11-2/#vp-dateTimeCanRep 15:12:45 ... 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 15:14:37 ... this approach means that Signature works, efficiency is supported, and developers can preserve formats if needed without modifying a document data model. 15:16:25 DP: discussing duration types 15:17:05 XML Schema (to the rescue, again) discusses duration types 15:17:26 ... 3.3.6 duration https://www.w3.org/TR/xmlschema11-2/#duration 15:18:06 ... https://www.w3.org/TR/xmlschema11-2/#yearMonthDuration and https://www.w3.org/TR/xmlschema11-2/#dayTimeDuration 15:19:49 ... https://www.w3.org/TR/xmlschema-2/#duration 15:24:56 discussion on timezone issues... 15:25:53 my expectation is that they had a similar discussion when designing XML schema; they kept timezone optional, in variable and canonical forms 15:30:52 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 15:31:15 aha, dates themselves are only numeric, so performance is not an issue 15:31:29 Properties of Date/time Seven-property Models https://www.w3.org/TR/xmlschema11-2/#dt-dt-7PropMod 15:32:38 Summary for me today: preserving Signature validity is very important so please let's address this. 15:33:45 not sure what happened but webex disconnected my voice line! no more thinking together allowed today... 15:34:13 again thanks for great discussion, see you next time 15:34:42 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. 15:39:57 rrsagent, create minutes 15:39:57 I have made the request to generate http://www.w3.org/2016/04/26-exi-minutes.html taki 16:00:39 taki has left #exi 16:30:53 Zakim has left #exi