- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 21 May 2012 20:50:00 +0200
- To: liam@w3.org
- Cc: Takuki Kamiya <tkamiya@us.fujitsu.com>, SVG public list <www-svg@w3.org>, member-exi-wg@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