Re: [apps-discuss] +exi

[Julian Reschke <[e-mail]>]

On 2011-12-13 22:19, Peter Saint-Andre wrote:
> On 12/13/11 11:02 AM, SM wrote:
>> At 09:45 13-12-2011, Peter Saint-Andre wrote:
>>> 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.
>>
>> I don't know whether Item B at
>> http://www.ietf.org/proceedings/78/minutes/yam.txt is relevant to the
>> discussion.
>
> Sort of. :)
>
> The case of gzipped SVG is a good example of an encoding of a content

Well, until people start looking for a content type to map their "svgz" 
files to, or need to embed gzipped SVG into a data URI.

The decision to clarify that "image/svg+xml" isn't useable for that was 
right, but this use case may really required a separate content type.

> type. The case of a binary representation of an XML infoset might be an
> example of a content type (as opposed to a compressed encoding of
> textual XML, which I think we all agree is an encoding of a content
> type). Before IETF 82, I was not aware of the EXI mode that represents
> an XML infoset directly in binary, but some folks there enlightened me,
> so I think there is more subtlety here than was reflected in this thread
> in early November.

I'm not sure that I understand the difference. Both are compression 
formats. One may be specialized for XML, but otherwise?

Best regards, Julian