Efficient Extensible Interchange Working Group Teleconference

10 Jan 2017

See also: IRC log




C24.biz - "Turn your XML into binary - JavaOne 2014"

<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.

Grammar String

<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)

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/01/10 20:13:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]