18:33:32 RRSAgent has joined #exi 18:33:32 logging to http://www.w3.org/2017/01/10-exi-irc 18:33:34 RRSAgent, make logs public 18:33:34 Zakim has joined #exi 18:33:36 Zakim, this will be EXIWG 18:33:36 ok, trackbot 18:33:37 Meeting: Efficient Extensible Interchange Working Group Teleconference 18:33:38 Date: 10 January 2017 18:37:48 TOPIC: C24.biz - "Turn your XML into binary - JavaOne 2014" 18:38:00 DB: It was similar to what we did in XBC. 18:38:32 DB: Compress XML into binary. It may be good idea to invite the person to EXI. 18:38:51 DB: I do not personally know him. 18:39:08 DB: He seems to be in stock transaction business. 18:40:03 brutzman has joined #exi 18:40:42 I saw another news article of potential interest this week... 18:41:23 NY Times, "Google Helping Mobile Publishing? Some Publishers Are Not So Sure" https://www.nytimes.com/2017/01/01/technology/google-amp-mobile-publishing.html 18:42:11 subject is AMP, or Accelerated Mobile Pages 18:43:08 Release article NY Times, "Google Joins Race to Speed Up Mobile Delivery of News Articles" 24 FEB 2016, https://www.nytimes.com/2016/02/25/technology/google-joins-race-to-speed-up-mobile-delivery-of-news-articles.html 18:43:20 DP: AMP restricts HTML5. HTML5 is huge, and can slow down browsers. 18:44:17 ... so anyway, many of the original motivations for AMP are capabilities that are already present in EXI. this might influence our integration and outreach strategies for EXI in 2017. 18:46:47 last year I asked if W3C Communications Team might help us put together the EXI story better. Creating such a sharable reference still seems like it might provide significant benefit to EXI and W3C. 18:50:13 coming up with strategic goals for 2017 can be helpful 18:50:55 DP: W3C Blog Post was excellent. However no response received 18:52:11 W3C Blog, "Efficient representation for Web formats," 22 November 2016 by Daniel Peintner, https://www.w3.org/blog/2016/11/efficient-representation-for-web-formats/ 18:53:31 suggestion: 2 agenda categories each week, Communications and Strategy 18:54:59 FWIW there's an automatic posting on twitter on blog posts 18:55:10 W3C twitter is https://twitter.com/w3c @w3c 18:56:08 The blog post on EXI never appeared on twitter, the last W3C tweet on EXI was 2014 18:57:34 I again recommend that we again ask W3C Communications Team what they can do to help us. It would be great if they joined a teleconference. 18:57:44 https://twitter.com/w3c/status/801430985686614018 18:58:09 DP: Do you know whether CSS people had a chance to take a look at our proposal yet? 18:58:33 CB: They will have Face-to-Face this week. I am going to ping team contact. 18:58:42 Thanks for tweet link Carinne, "Efficient representation for Web formats, by Daniel Peintner" 18:59:10 ... curious that my 2 searches within twitter and on google didn't reveal that. much appreciated. 19:01:02 ... maybe the tweet wasn't discovered (searched on "@w3C exi) because we didn't have a hash tag? perhaps we should start a #EXI hash tag. it would be good to get their feedback on that. 19:13:29 TOPIC: Grammar String 19:14:31 DP: I did implement grammar strings in EXIficient to see how the conecpt works. 19:14:47 DP: Currently, we only support strings. 19:15:19 DP: When I did implement it, I found it very strange to have limited it to strings. 19:15:58 DP: Date-time, etc. If you don't limit to strings, we can simply use enumeration codec mostly. 19:17:06 Perhaps a more generic term for that capability is "typed enumerations" 19:17:57 DP: The amount of code is essentially the same. 19:18:25 s /"typed enumerations"/"arbitrarily typed enumeration values" 19:21:00 we might find some interesting uses... common math constants, public key values (e.g. authenticate from W3C), values in an XML schema enumeration type etc. 19:22:20 one possibility is to take an arbitrary typed value, if it can be deterministically mapped to an unambiguous string then that is a pretty general path. 19:23:55 DP: found ~200 common CSS property names, performance can get worse if many are used because more bits are needed. surprising tradeoffs, not necessariliy best solution in all situations. 19:24:16 https://github.com/EXIficient/exificient-for-css/blob/master/src/main/resources/exi4css.xsd 19:25:03 https://github.com/EXIficient/exificient-for-css/blob/master/src/main/resources/exi4css.xsd#L91 19:26:34 aren't there well-defined CSS values already? tables could be predefined. if sorted by frequency of common usage, then a variable-length encoding can be utilized 19:27:46 Example VLE is Huffman encoding https://en.wikipedia.org/wiki/Huffman_coding 19:28:04 s/VLE/Variable Length Encoding (VLE)/ 19:29:37 this would seem to benefit both compactness and performance at once: table is not transmitted, table is precomputed (rather than every time), only have to use codes of interest. 19:30:07 DP: haven't seen many schemas with 200 enumerations 19:30:30 ... though there are many vocabularies with more terms than that. 19:31:44 wondering how to record frequency priority in a schema? 19:32:27 DP: compressor can measure whether better performance is possible using regular string table instead of enumerations 19:35:07 wondering, is a general capability possible by supporting non-string types for xs:baseType attribute use for and values 19:36:01 .. so doesn't that produce a set of "typed enumeration values" that is not necessarily a string? 19:37:12 DP: my original point was to use any type, not just string 19:37:41 ... good, so it would appear that XML schema has such expressibility already defined? 19:40:39 DP: discussed strict versus nonstrict. If a piece of data is not in the predefined strict list, how to handle it? also what if the value is significantly different? 19:41:07 ... the structure needs to fit, or it can't be transformed back again. 19:44:54 DP: discussion of CSS extensions 19:46:07 interesting XML schema actually lets you define a simpleType and either use it for strict typing, or simply be present. so this is the same as whether an enumeration is present and extensible; no validation occurs. 19:47:50 https://www.w3.org/XML/EXI/docs/extendedString/exi-extString.html#grammarString 19:47:55 so aspects of interest for enumerations: data type (simpleType @baseType, or "grammar string"), whether strict or extendible; priority ordering if VLE occurs 19:50:09 note that if EXI-related information of interest can be unambiguously represented in the XML schema, then that can be shared beforehand and run-time sharing is much terser/simpler 19:52:34 DP: good design is often to make enumerations strict 19:53:09 ... yes, "OTHER" can be an enumeration and an separate otherValue field can be part of design. 19:54:25 TK: EXI Options provide some possibilities 19:55:12 ... but those are on a document-wide basis. We might want EXI appinfo annotations to designate an "option" for an element or an attribute 19:56:21 if we follow schema and only allow strict typing for enumeration simpleTypes, that also keeps everything more efficient. 19:57:17 TK: sees slight difference for using annotations in a schema, but must not change validation 19:57:30 s/TK:/DP:/ 19:59:07 so maybe just 2 new aspects of interest: (a) support arbitrary type in baseType of enumeration list, and (b) allow option for VLE of a simpleType enumeration list 19:59:44 DP: Currently, we have only strict and non-strict. 20:00:24 DP: Sometimes, structure can be strict, but value cannot be strict. 20:00:50 DP: we currently have 2 options (strict, which is very strict) or nonstrict for attribute values or simple element content 20:02:36 DP and TK: support for arbitrary type in enumeration lists is already supported 20:08:23 (we had some difficulty describing exactly what happens in a grammar string - more examples would help) 20:13:31 rrsagent, create minutes 20:13:31 I have made the request to generate http://www.w3.org/2017/01/10-exi-minutes.html taki 20:38:44 Zakim has left #exi