Re: [apps-discuss] +exi

[Carine Bournez <[e-mail]>]

On Tue, Dec 13, 2011 at 10:45:19AM -0700, Peter Saint-Andre wrote:
> I chatted with a few folks about this in Taipei and afterward.
> 
> As I understand it (correct me if I'm wrong), EXI has two modes:
> 
> 1. Straight compression of the text representation of XML (text in,
> EXI-compressed data out). To make use of the data, you then decompress
> it back into the angle-brackety text representation of XML that we all
> know and love.
> 
> 2. Direct, binary representation of the XML infoset. In this case, you
> never have the data in a angle-brackety text representation, instead it
> is always a binary representation.

It is not exactly 2 modes. The EXI 1.0 Recommendation only specifies a 
compressed encoding of an XML Infoset. Applications that include an EXI 
processor may use different approaches around the encoding/decoding process. 
So, you can have applications with a (text) XML document as an input
(what you describe as #1), and applications that never use a text
serialization (your #2).

> It seems to me that #1 is similar to gzip, i.e., the textual
> representation is encoded using EXI compression, so we'd have this:
> 
>    Content-Type: application/foo+xml
>    Content-Encoding: exi
> 
> It seems to me that #2 might not be an encoding of the relevant +xml
> content type, but might be a different content type, so +exi might be
> appropriate.

The W3C EXI Working Group has decided not to follow the +exi path, 
since it involved a potentially infinite number of types to register.
There could also be conformance issues: an EXI stream not encoded
from a text version might not be necessarily serialized as a conformant
"foo" after decoding from its EXI form. It needs some specification 
work for each foo+exi.
The generic application/exi content-type is meant to be used for cases 
where there is no serialization from/to a standard format (then no 
content-type can be used), as well as for protocols that have no 
content-encoding capability.


-- 
Carine Bournez -+- W3C Europe