14:11:48 <RRSAgent> RRSAgent has joined #exi
14:11:48 <RRSAgent> logging to http://www.w3.org/2016/07/05-exi-irc
14:11:50 <trackbot> RRSAgent, make logs public
14:11:50 <Zakim> Zakim has joined #exi
14:11:52 <trackbot> Zakim, this will be EXIWG
14:11:52 <Zakim> ok, trackbot
14:11:53 <trackbot> Meeting: Efficient XML Interchange Working Group Teleconference
14:11:53 <trackbot> Date: 05 July 2016
14:12:39 <taki> TOPIC: EXI4JSON
14:14:15 <taki> DP: If keyname cannot be represented using NCName, then we just say you should it differently. We may need more guidance in the future.
14:14:42 <taki> http://www.w3.org/XML/EXI/docs/json/exi-for-json.html
14:16:11 <taki> DP: What's the next step?
14:17:04 <taki> DP: Do we need to provide any measurement?
14:17:44 <dape> https://www.w3.org/XML/EXI/docs/json/exi-for-json.html#decisionStructureChange
14:17:45 <taki> TK: Did we describe what we changed?
14:18:13 <taki> DP: C.4 describes what we changed.
14:19:10 <brutzman> when ready, have some questions on Sections 3.1.1 JSON object and 3.2.8 key Elements
14:22:05 <taki> DP showing appendix D...
14:22:48 <taki> DP: In the new structure, key is an element name.
14:23:03 <taki> DP: It used to be an attribute value.
14:23:19 <taki> DP: This way, we can define a proper schema.
14:24:18 <brutzman> Suggestion for Appendix D Examples.  insert rows with title and brief description so that we can refer to them
14:25:22 <taki> DB: I suggest to describe what each row in appendix D is about.
14:25:57 <taki> DB: We can also descibe the change by example in C.4.
14:26:04 <taki> s/DB/DP/
14:29:01 <taki> DP explaining the changes by using examples...
14:30:41 <brutzman> I found the terms "keyName" and "keyNumber" a little confusing because they looked like reserved terms with special significance.
14:31:28 <brutzman> ... probably because you had "keyname" in 3.1.1 https://www.w3.org/XML/EXI/docs/json/exi-for-json.html#N65938
14:32:25 <brutzman> DP: yes  the term "keyname" in 3.1.1 is reserved for that use
14:32:58 <taki> DP: "a number" is an invalid name in XML.
14:33:43 <taki> DP: We use *any* element name (e.g. "A"), and place the real name in "keyname" child element.
14:35:16 <taki> DB: Is "ANY_NAME" a synonym introduced by author?
14:35:34 <taki> DP: We will need a guidance when we need to use it.
14:36:18 <taki> DB: It is better if we had a convention as to how to name it.
14:36:36 <taki> DP: I agree. We had a discussion.
14:38:50 <brutzman> Perhaps key "1 %" can be "NCNAME_1_%" or NCNAME_1_escapeCharacter" ?
14:41:09 <brutzman> what about <j:structure><j:keyname>a number</j:keyname></j:structure>
14:41:51 <brutzman> ... or <j:object><j:keyname>a number</j:keyname></j:object>
14:44:01 <brutzman> extrapolating: <j:object><j:keyname>a number</j:keyname><j:number>s1</j:number></j:object>
14:48:49 <taki> DP: The alternative is to define a convention that can convert between JSON name and corresponding XML name.
14:49:10 <brutzman_> brutzman_ has joined #exi
14:49:22 <brutzman_> DP: ... because you cannot have an array that includes different content models within it
14:50:42 <brutzman_> if we backtrack to where "a number" was changed to >j:A> then what appears to be needed is come kind of canonicalization of any key that does not pass NCNAME requirements
14:52:38 <brutzman_> Please confirm, that outer <j::A> or else <j:a_number> (or whatever canonicalization is used) goes away in the final reconstituted JSON
14:52:55 <brutzman_> s/j::A/j:A/
14:54:25 <brutzman_> DP: yes it goes away on reconstruction when the <j:keyname> element is found [gave example on screen capture]
14:55:14 <brutzman_> So is the next requirement for consistency to have a unique canonicalization?
14:55:53 <brutzman_> DP: canonicalization not necessary, the naming is syntactic sugar since it goes away anyway
14:56:33 <brutzman_> so the critical aspect is that the subsituted name is unique?  is that something tools should have liberty to choose?  might make parsing harder...
14:57:40 <brutzman_> if a tool is making up names arbitrarily, the chosen values might collide with other keys in the document.
14:57:57 <brutzman_> signature comparison would also be thwarted
14:59:55 <brutzman_> DP: duplication of key names in two forms (non-NCNAME and perhaps canonicalized) reduces compactness
15:01:20 <brutzman_> EXI4JSON document could note that choice of a non-NCNAME key is allowed but can reduce compactness
15:03:08 <brutzman_> Letting a compressor chose alternate names (A, , C or whatever) also reduces compactness, in addition to possibly resulting in element-name collisions
15:03:37 <brutzman_> s/A, , C/A, B, C/
15:09:21 <brutzman_> wouldn't JSON { "keyname" : 3 } simply map to <j:keyname>3</j:keyname>
15:09:56 <brutzman_> DP: (showing example) no because "j:keyname" is reserved
15:10:59 <brutzman_> 3.2.8 key Elements https://www.w3.org/XML/EXI/docs/json/exi-for-json.html#N66387 "A key element is any element other than j:map, j:array , j:string , j:number , j:boolean , j:null , j:other, j:base64Binary, j:dateTime, j:time, or j:date, j:integer or j:decimal, j:keyname, and is transformed to ..."
15:11:57 <brutzman_> doesn't this imply that a JSON author can't directly use a reserved keyword like boolean?
15:14:14 <taki> DP: On the encoder side point of view, the name also can't conflict with reserved EXI4JSON element names.
15:14:15 <brutzman> brutzman has joined #exi
15:14:52 <brutzman> thus keyname sustitution is unavoidable, and thus necessary, for this entire EXI4JSON approach to work
15:16:26 <brutzman> so my recommendation is to canonicalize keyname substitution for both the reserved elements and for the non-NCNAME j:keyname elements
15:18:13 <brutzman> i suspect that since j:keyword escaping might require special handling by EXI compressor and EXI decompressor in any case, perhaps compactness won't be affected if we find a good canonicalization scheme
15:20:14 <brutzman> one naive canonicalization: EXI4JSON_boolean or EXI4JSON_a_number or EXI4JSON_1_escapeCharacter
15:20:46 <brutzman> ... which has the benefit of being human readable/deducible
15:21:22 <brutzman> a more formal approach might be URL canonicalization, if that passes NCNAME requirements.
15:22:51 <brutzman> s/URL canonicalization/to adapt URL canonicalization/
15:24:13 <brutzman> RFC 3986 Uniform Resource Identifier (URI): Generic Syntax https://tools.ietf.org/html/rfc3986 section 3.1
15:25:56 <brutzman> I don't know that URI scheme is necessarily best, but it is well understood and widely implemented.
15:26:07 <brutzman> DP: what about forced lowercase?
15:26:28 <brutzman> That is just for hostname, so we would need to skip that part
15:27:37 <brutzman> Another (perhaps even simpler) approach is XML/HTML character entities https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references
15:28:31 <brutzman> XML Entity Definitions for Characters (2nd Edition) W3C Recommendation 10 April 2014 http://www.w3.org/TR/xml-entity-names
15:28:57 <brutzman> DP: pointed out some difficulties on his screen capture
15:30:04 <brutzman> i think our main challenge for keyname-sustitution canonicalization is uniquess; compaction will be a lesser factor
15:33:54 <brutzman> perhaps unique and bidirectional isn't possible for mapping keys to NCNAME?  this is always the challenge for escape schemes.
15:33:55 <brutzman> since keyname sustitution is required, perhaps we should instead create a string table that complements the schema (without name collisions)?
15:36:01 <brutzman> ... in other words, instead of just trying to solve the problem with unique escaping, is there another feature of EXI and XML that we might also apply?
15:39:02 <brutzman> we could define a subsitution table in the reserved words, and thus simply make it a lookup when reconstituting JSON.  this would let tools pick whatever names they wanted, unambigously.
15:39:44 <brutzman> a tool could also choose names that were helpful for compaction and not colliding, for example:  A B D E G
15:44:16 <brutzman> wondering if there might be yet another variation here: making the EXI4JSON schema a separate namespace.  Then include a subsitution-table mechanism there.  This avoids doing 2 things with one schema.
15:45:55 <brutzman> Separation of the problem that causes name collisions might simplify the algorithm.
15:47:19 <brutzman> A further option might also be:  "JSON authors who want to take advantage of schema-informed EXI compaction should avoid using the keywords of 3.2.8 and ensure that all keys are legal NCNAME values.
15:47:44 <brutzman> s/values./value."/
15:49:17 <brutzman> That has the advantage of simplicity, for end users and for implementations.
15:50:34 <brutzman> Problem cases we are worried about (keys such as "1 %") are perhaps not carefully designed object structures anyway...
15:51:24 <brutzman> old joke.  patient says: "Doctor doctor, my arm hurts when i move it like this...."
15:52:23 <brutzman> ... Doctor: "OK, so don't move your arm like that.  Now please pay the nurse $100."
15:54:01 <taki> rrsagent, create minutes
15:54:01 <RRSAgent> I have made the request to generate http://www.w3.org/2016/07/05-exi-minutes.html taki
16:14:13 <Zakim> Zakim has left #exi
16:27:59 <taki> taki has left #exi