Re: [apps-discuss] +exi (was: Re: type name suffixes)

[Zach Shelby <[e-mail]>]

On Nov 16, 2011, at 11:06 AM, Bjoern Hoehrmann wrote:

> * Peter Saint-Andre wrote:
>> So, let's say I have "foo" data that can be represented in either plain
>> old XML or as EXI. If I send that "foo" data as plain old XML, the
>> "application/foo+xml" media type is right. If I send that "foo" data as
>> EXI, the "application/foo+exi" media type seems wrong, and so does the
>> "application/exi" media type (just as "application/xml" would not be
>> right for the first encoding). Sure, I don't particularly want to
>> duplicate all "+xml" entries with "+exi" entries, but I don't think that
>> every protocol or community that sends around XML data will also send
>> around EXI-encoded data.
> 
> The idea is that "EXI" is more like "gzip", so with HTTP you would do
> 
>  Content-Type: application/foo+xml
>  Content-Encoding: exi
> 
> As you would for gzip-compressed content.

Ouch, don't do that. 

The main interest right now for EXI is in constrained networks, and in particular over CoAP. We don't have support for indicating content-encoding in CoAP. Besides, the current media type for EXI is application/exi. Thus it would make perfect sense to have +exi entries. Furthermore, EXI is totally different than gzip, which is a generic encoding that can be applied to anything. EXI can be applied only to XML objects, and in particular EXI is often used in a schema mode where it is only applicable to a single schema. Thus the form application/schema+exi makes even more sense, as that EXI format is actually specific to that particular schema and the media type tells you everything that is needed to decode the representation. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]