W3C home > Mailing lists > Public > www-svg@w3.org > May 2012

Re: EXI WG's inquiry about ISSUE-2050

From: Robin Berjon <robin@berjon.com>
Date: Mon, 21 May 2012 20:50:00 +0200
Cc: Takuki Kamiya <tkamiya@us.fujitsu.com>, SVG public list <www-svg@w3.org>, member-exi-wg@w3.org
Message-Id: <145CD123-988C-4105-ACFD-30FD3054770D@berjon.com>
To: liam@w3.org
On May 21, 2012, at 17:40 , Liam R E Quin wrote:
> On Mon, 2012-05-21 at 14:04 +0200, Robin Berjon wrote:
>> XSD couldn't capture context-dependent constraints.
> XSD 1.1 has some support for this.

Right (though IIRC EXI doesn't make use of that?)

>> My experience with binarising SVG is that you gain most from custom
>> codecs (or by changing the syntax, which is essentially the same) and
>> less than you'd hope from the structural redundancy.
> One difference (as of course you know) between EXI and some of the
> others is that one could have e.g. a degooper that generated SAX events,
> with nary a pointy bracket in sight.

Indeed, which can help produce a more regular SVG tree  but in this specific case that won't buy you a lot. The problem is that the content model for a lot of elements is choice(lots of options){0,*} and each of those elements has dozens of optional attributes  which will tend to be costly to encode even when schema-informed. Hence the suggestion to experiment with encoding the rarer ones as errors. I wouldn't be surprised if the result came out smaller in most cases.

> Overall, using EXI with serialized HTML 5 might also be a worth-while
> goal, including embedded mathml and svg.

Yes, I would dearly love to see EXI applied to HTML.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 21 May 2012 18:50:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:35 UTC