Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt

[Tony Hansen <[e-mail]>]

Sometimes wikipedia actually has useful information. :-) From the 
wikipedia entry for EXI:

"An advantage of EXI over Fast Infoset is that EXI (optionally) uses 
more constraints from the XML schema. This can make the EXI data more 
compact; for example, if the XML schema specifies that elements named 
'bar' may only exist within elements named 'foo', EXI can assign a 
shorter token to the 'bar' element, knowing that it doesn't have to 
share the same token space as elements that occur elsewhere in the document.

"The main disadvantage is that to take advantage of this 
"schema-informed" compression, not only does the document require a 
schema, but the decoder needs a copy of the same schema that the encoder 
used."

This supports Ned's comment that +exi might not be viable.

     Tony Hansen

On 4/11/2012 11:57 AM, Ned Freed wrote:
>> If decoding requires additional information, than IMHO you can't use
>> HTTP's Content-Coding or Transfer-Encoding. By all means, if you think
>> otherwise then send feedback to the HTTPbis WG.
>
> Julian is 100% correct here. If EXI requires knowledge of the type 
> itself, it's
> not a separable encoding, which is what Content-Coding, 
> Transfer-Encoding, and
> Content-Transfer-Encoding all require. And while I suppose we could 
> adopt the
> foo+exi approach, having an explosion of encodings is a really bad idea.
>
> And if this is the case, it really isn't suitable for a +exi suffix 
> either.
> +exi is supposed to mean the format can at least be parsed,  
> independent of any
> knowledge of the type semantics. This is why I support the idea of 
> having +ber
> and +der but not +per - with +per you have to know the ASN.1 schema in 
> order to
> parse the material properly.
>
> For better or worse, we don't currently have a place in the 
> architecture for
> these entities. We could define some other sort of type naming 
> convention if
> there's really a need for it, but adding additional out of band 
> information
> that has to be processed in order to interpret the material correctly 
> is rather
> obviously highly problematic.