15:03:07 RRSAgent has joined #exi 15:03:07 logging to http://www.w3.org/2016/03/01-exi-irc 15:03:09 RRSAgent, make logs public 15:03:09 Zakim has joined #exi 15:03:11 Zakim, this will be EXIWG 15:03:11 I do not see a conference matching that name scheduled within the next hour, trackbot 15:03:12 Meeting: Efficient XML Interchange Working Group Teleconference 15:03:12 Date: 01 March 2016 15:05:35 dape has joined #exi 15:08:40 scribe: TK 15:08:46 scribeNick: taki 15:09:32 brutzman has joined #exi 15:09:52 TOPIC: EXI for JSON 15:10:08 DP: In EXI2 topics, there are related topics. 15:11:03 https://lists.w3.org/Archives/Public/public-exi/2015Nov/0000.html 15:12:00 DP: Shared strings idea. In our use cases, JSON-LD is heavily loaded with strings that are well-known. 15:12:19 DP: Currently EXI does not provide any help for that. 15:12:37 DP: Is the group interested in this? 15:15:52 DP: The document also includes some other features. 15:16:59 DP: Grammar string, shared string and split string. 15:17:57 spellilng in sectijon 5: requierements -> requirements 15:18:53 s/sectijon/section/ 15:19:51 DP: We can use DTRM to map string encoding to this extentension string representation. 15:20:14 TK: I can help advancing this document. 15:20:32 Presumably any computational cost of figuring out whether a given substring is part of the shared-string vocabulary only occurs during encoding. When decoding, it is essentially just a table lookup. Is that correct? 15:21:12 s/extentension/extension/ 15:21:29 DP: yes that is true. 15:21:34 DP: Yes, that is correct. Decoder side just needs to look up the table. 15:21:52 Good, so there will be no noticeable impact on performance. 15:22:12 DB: No noticeable performance impact on encoder side is good. 15:22:50 DB: The idea is EXI WG is not the right place to define strings. 15:22:55 s/DB/DP/ 15:22:58 Next, wondering what strings to use, are they selected by EXI working group? 15:23:58 perhaps this is an extension mechanism as well? Different groups might have different vocabulary tables? Alternatively these might just be schema enumerations. 15:25:20 DP: EXI currently does not pre-populate string values from schemas. 15:26:05 DP: String value tables in EXI are always empty. Grammar strings should be allowed to be pre-populated. 15:26:20 A schema-based mechanism can be a good way to solve the need for vocabulary definition. Presumably enumerations are encoded. This could be a recommended practice for EXI use of schemas. 15:29:43 I think that XML Schema offers many capabilities which we ought to take advantage of. For example, if you applied EXI compression to a well-defined W3C Recommendation schema, then it would create a string table for you based on defined elements attributes and enumeration strings. 15:30:54 The list might be large by default, but stable schemas don't need to be installed more than once. Further the size of the table isn't an issue, especially if the schema table is external. 15:32:15 Stability of schema is simply a choice of document users: either a stable well-defined schema, or a flexible evolving schema. This approach is useful either way... 15:32:51 ... because it takes care of the coordination requirement when defining a "fixed" string table. 15:33:45 DP: I agree we should look for a way to allow to use strings in schemas. 15:33:50 It would at least be good to identify relevant supporting capabilities from XML schema in the note above. 15:34:03 DP: Whether we use all of them, or some of them, I am not sure yet. 15:36:02 It is also possible to say (a) a shared-string table has same structure as compressed schema enumerations, (b) a schema could be annotated to let a shared-string table generator extract enumerations of interest. 15:36:38 Am happy to contribute schema considerations to the Note. 15:37:48 I think that there is a lot more we might do with XML Schema and EXI, including usage of EXI-compressed XML schemas in support of streaming and common W3C document formats. 15:38:12 DB: Do we talk much about schema in EXI 2? 15:40:03 I see 5 issues already... we should list new version of XML Schema v1.1 as well... these issues might be grouped together so that comprehensive XML Schema support in EXI can be pursued. 15:41:13 For example I think this also relates to various list dialogs about HTML5 and compression. 15:42:09 Does anyone know why there is no XHTML schema for HTML5? 15:42:25 Is the X in XHTML not XML? 15:45:17 CB: HTML5 documents are not XML. 15:45:34 s/HTML5/most HTML5/ 15:46:13 DB: They are loaded into DOM, then can be serialized into XHTML. 15:46:15 If an HTML syntax page for HTML5 is loaded, it goes into DOM unambigously, and then can be serialized as XHTML unambiguously. 15:46:28 CB: That doesn't immediately make them XML. 15:47:07 CB: Syntactically, it is not XML. It just loads into DOM4. 15:47:47 I think if we then transform DOM into XHTML markup, we have something that EXI can compress. 15:48:30 Relevance of this use case: Accelerated Mobile Pages Project https://www.ampproject.org has a few characteristics in common 15:48:48 CB: That is subset of HTML that can compress better for mobile use cases. 15:49:13 DP: Subsetting HTML5. 15:49:29 DP: It is still HTML. Not XML. 15:51:09 Nothing seen in AMP FAQ regarding compression 15:52:04 I bring it up to point out that faster loading of mobile web pages is considered important. There has also been press interest on this project. 15:52:37 So higher-performance HTML pages seems to be an important goal for EXI as well. 15:53:51 It looks to me like the only missing is an XHTML schema for HTML5. That would let us apply EXI to HTML pages right away, enabling testing on size & performance & all of the other good things that EXI excels at. 15:56:34 We might further focus on CSS compression. We would then have HTML and JSON and CSS, plus MathML... most of the way. 15:57:34 If we then tried to get EXI to work compatibly with CBOR (or another Javascript compression scheme) then a comprehensive solution is emerging. 15:59:14 Robin made some experiments on using EXI on html docs a few years ago 15:59:39 If HTML5.1 isn't working on a schema, we could ask them to do so or else declare reasons why not. 16:00:12 If HTML5.1 doesn't care about XHTML XML syntax, the EXI group could define a schema and invite improvements and note limitations. 16:00:45 s/we could/EXI working group could/ 16:01:47 This doesn't break anything. What's not to like? 8) 16:02:45 Perhaps Liam or someone can give us insight into XHTML XML HTML5 issues... 16:03:56 Agreed that Robin would have an excellent insight regarding these matters also. 16:05:58 [ polyglot HTML is *both* XML syntax *and* HTML syntax ] 16:08:54 CB: Applying XPath on HTML5. There are parallel issues. HTML5 is no longer XML. 16:09:54 I think we need to be precise on this topic. HTML5 includes both HTML Syntax and XHTML Syntax, with both mapping to a common DOM in a well-defined manner. 16:11:57 HTML5 section 8 The HTML syntax https://www.w3.org/TR/html/syntax.html#syntax 16:12:40 HTML5 section 9 The XHTML syntax https://www.w3.org/TR/html/the-xhtml-syntax.html#the-xhtml-syntax 16:13:29 So if we try to produce (or contribute to) an XML schema that supports XHTML representation of HTML5 DOM, then that seems quite useful for EXI. 16:13:41 TOPIC: Canonical EXI 16:13:59 TOPIC: ISSUE-110: What to do with xml:space being preserved in strict mode 16:14:53 TOPIC: Whitespace preservation mode 16:16:33 https://lists.w3.org/Archives/Public/public-exi/2016Feb/0021.html 16:16:46 s/the only missing/the only thing missing/ 16:18:13 DP: Canonical EXI requires to use typed production first. 16:23:17 DP: xml:preserve have conflicts with strict mode. 17:03:19 rrsagent, create minutes 17:03:19 I have made the request to generate http://www.w3.org/2016/03/01-exi-minutes.html taki 17:27:23 Zakim has left #exi