See also: IRC log
<taki> DB: It was similar to what we did in XBC.
<taki> DB: Compress XML into binary. It may be good idea to invite the person to EXI.
<taki> DB: I do not personally know him.
<taki> DB: He seems to be in stock transaction business.
I saw another news article of potential interest this week...
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
subject is AMP, or Accelerated Mobile Pages
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
<taki> DP: AMP restricts HTML5. HTML5 is huge, and can slow down browsers.
scribe: 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.
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.
coming up with strategic goals for 2017 can be helpful
DP: W3C Blog Post was excellent. However no response received
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/
suggestion: 2 agenda categories each week, Communications and Strategy
<caribou> FWIW there's an automatic posting on twitter on blog posts
W3C twitter is https://twitter.com/w3c @w3c
The blog post on EXI never appeared on twitter, the last W3C tweet on EXI was 2014
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.
<caribou> https://twitter.com/w3c/status/801430985686614018
<taki> DP: Do you know whether CSS people had a chance to take a look at our proposal yet?
<taki> CB: They will have Face-to-Face this week. I am going to ping team contact.
Thanks for tweet link Carinne, "Efficient representation for Web formats, by Daniel Peintner"
scribe: curious that my 2
searches within twitter and on google didn't reveal that. much
appreciated.
... 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.
<taki> DP: I did implement grammar strings in EXIficient to see how the conecpt works.
<taki> DP: Currently, we only support strings.
<taki> DP: When I did implement it, I found it very strange to have limited it to strings.
<taki> DP: Date-time, etc. If you don't limit to strings, we can simply use enumeration codec mostly.
Perhaps a more generic term for that capability is "typed enumerations"
<taki> DP: The amount of code is essentially the same.
s /"typed enumerations"/"arbitrarily typed enumeration values"
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.
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.
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.
<dape> https://github.com/EXIficient/exificient-for-css/blob/master/src/main/resources/exi4css.xsd
<dape> https://github.com/EXIficient/exificient-for-css/blob/master/src/main/resources/exi4css.xsd#L91
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
Example Variable Length Encoding (VLE) is Huffman encoding https://en.wikipedia.org/wiki/Huffman_coding
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.
DP: haven't seen many schemas
with 200 enumerations
... though there are many vocabularies with more terms than
that.
wondering how to record frequency priority in a schema?
DP: compressor can measure whether better performance is possible using regular string table instead of enumerations
wondering, is a general capability possible by supporting non-string types for xs:baseType attribute use for <xs:simpleType> and <xs:enumeration> values
scribe: so doesn't that produce a set of "typed enumeration values" that is not necessarily a string?
DP: my original point was to use
any type, not just string
... good, so it would appear that XML schema has such
expressibility already defined?
... 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?
... the structure needs to fit, or it can't be transformed back
again.
... discussion of CSS extensions
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.
<dape> https://www.w3.org/XML/EXI/docs/extendedString/exi-extString.html#grammarString
so aspects of interest for enumerations: data type (simpleType @baseType, or "grammar string"), whether strict or extendible; priority ordering if VLE occurs
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
DP: good design is often to make
enumerations strict
... yes, "OTHER" can be an enumeration and an separate
otherValue field can be part of design.
TK: EXI Options provide some
possibilities
... but those are on a document-wide basis. We might want EXI
appinfo annotations to designate an "option" for an element or
an attribute
if we follow schema and only allow strict typing for enumeration simpleTypes, that also keeps everything more efficient.
DP: sees slight difference for using annotations in a schema, but must not change validation
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
<taki> DP: Currently, we have only strict and non-strict.
<taki> DP: Sometimes, structure can be strict, but value cannot be strict.
DP: we currently have 2 options (strict, which is very strict) or nonstrict for attribute values or simple element content
DP and TK: support for arbitrary type in enumeration lists is already supported
(we had some difficulty describing exactly what happens in a grammar string - more examples would help)
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/VLE/Variable Length Encoding (VLE)/ Succeeded: s/TK:/DP:/ No ScribeNick specified. Guessing ScribeNick: brutzman Inferring Scribes: brutzman WARNING: No "Present: ... " found! Possibly Present: CB DB DP TK caribou dape exi https joined suggestion taki trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy <amy> Present+ WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 10 Jan 2017 Guessing minutes URL: http://www.w3.org/2017/01/10-exi-minutes.html People with action items:[End of scribe.perl diagnostic output]