Re: [apps-discuss] +exi

[Paul Duffy <[e-mail]>]

Peter accurately described SEP2's intentions re: EXI usage.  We're 
essentially marshaling/un-marshaling an  internal infoset either...

1. direct to XML/text

2. direct to an EXI binary encoding.  Note these nodes never manipulate 
XML text.  This approach is particularly important for resource 
constrained nodes (i.e. memory not available to blow the EXI up into XML).

We tend to look at these as two different encodings, not one as a 
compression of the other.


On 12/13/2011 4:36 PM, Peter Saint-Andre wrote:
> On 12/13/11 2:58 PM, Carine Bournez wrote:
>> 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.
> Thank you for the clarifications.
>
> The example that raised this issue for me was the ZigBee Alliance Smart
> Energy Profile 2.0, which supports both a text serialization of their
> XML format and an EXI representation. Tom Herbst and Paul Duffy can
> describe that use case more accurately than I can, but based on what
> you've said it seems that they would use application/sep+xml and note a
> content encoding of EXI for the second case. However, it is possible
> that (if their transport/transfer protocols do not have a way to note
> the content encoding) they might use application/exi for the second
> case. I'll let Tom and Paul speak to that. Zach Shelby might also have
> opinions in the matter. In any case, I think they have the information
> they need to make the right decision in the ZigBee Alliance (and if not
> they can speak up).
>
> Peter
>