Re: [xml-dev] EXI: was : RE: [xml-dev] what's missing in XML?What's comi

[Liam R E Quin <liam@w3.org>]

On Mon, 2012-01-02 at 15:41 -0500, Richard Salz wrote:
> > it has, at least a little. We previously were seeing things like
> > XML-specific compression specs that didn't support mixed content, for
> > example.
> 
> Your perspective is much much wider than mine.  But, really, you are 
> seeing potential fragmentation that really posted a credible threat?  Are 
> or were seeing them? Any specifics you can point to?

There were over a dozen binary encodings of XML identified as being in
at least moderately significant use at around the time of the Workshop.

I don't have references without going digging, sorry. Fast Infoset was
obviously one; as I recall that was one where mixed content wasn't
initially supported at all.

The reasons for supporting the EXI work from my perspective were (1) to
stop proliferation, and (2) because it did seem there were advantages to
be gained over e.g. gzip, in some important (as I see it) use cases.

Actually, the single most compelling use case for me was actually
dropped: supporting random access into a document, e.g. with a table of
pointers to the start of each "page" element in a book. You can't do
that with text-based XML because of what I call the "XML Promise" -- any
XML processor is licensed to process any XML document, and of course
ones that didn't understand the byte-offset-table could break it.

However, other uses presented themselves for EXI that were also
compelling, and the result is indeed (it seems) better than gzip both in
decoder CPU/memory requirements and in bandwidth, or at least can be.

Note also that an EXI reader doesn't ever need to deal with pointy
brackets directly - not doing something is almost always faster than
doing something.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/