[apps-discuss] Feedback on draft-shelby-exi-registration-01

[Robin Berjon <[e-mail]>]

Dear all,

please find some notes below on the draft-shelby-exi-registration-01 proposal that describes a +exi media type suffix. Before I jump in, I would like to make it clear that these comments are strictly my own and are not made as any of former chair of the EXI WG, the XBC WG, or as member of the W3C TAG.


• It is mentioned that the +exi suffix is defined "for use in a specific class of protocols". It further seems to be implied that these protocols do not support conveying content encoding separately from the type. I think that it would be helpful to specify what those protocols are. Given the cost and impact of introducing a +exi structure suffix across the board, without that information I can only suspect that it may be both cheaper and simpler to update the relevant protocols.

Additionally, if those protocols are designed to be simpler, easier to process profiles of HTTP, given that the use case covers devices that obviously already have an EXI decoder, in absence of further information I also wonder if those protocols could not be replaced by some form of EXI-encoded HTTP (possibly minus a number of headers). But naturally this is just a speculation made in absence of information.


• Reading the following:
"""
The "+exi" Structure Syntax Suffix defined in this document is 
appropriate for use with a special class of protocols that:

   o  Make use of a Media Type to identify the semantics of the protocol
      payload, and offer more that one serialization of the payloads.
      For example, some protocols may offer JSON, XML and EXI
      representations"
"""
I cannot help but get a strong sense that this is actually making a case for using content coding rather than a structured suffix since it mirrors (certainly in the case of EXI) the semantics versus serialisation distinction. EXI was deliberately defined to be a content coding for XML; the group's decision to define an "exi" content coding rather than a +exi suffix was intentional and not an oversight.

Conflating content coding and media type seems at the very least strange to me. To take an example, we currently have image/svg+xml. This draft introduces image/svg+exi. Can you explain why that would be a good thing to introduce, and if it is should we also look into adding image/svg+gzip and image/svg+identity?


• This part "use EXI as a native encoding (without the use of XML as an interemediate)" worries me because it seems to stem from a rather fundamental misunderstanding of what EXI is. EXI is XML. There is no form of requirement to hop through XML Data Model -> XML -> EXI, and whichever way the EXI bitstream was produced really, really should be immaterial for any protocol transmitting it as well as for a potential media type registration.


• This is worrying: "The registration of a Media Type using this suffix MUST describe how to determine the XML Schema that is used to encode/decode a payload identified by that Media Type." What it does is register a generic suffix for a very specific usage. For instance, SVG has no XML Schema. The above therefore precludes SVG from potentially registering image/svg+exi (assuming it would be a sensible thing to do).

What's more, EXI is not limited to relying on schema information from XML Schema. It is perfectly valid to use DTDs, RelaxNG, JSON Schema, domain-specific knowledge, etc. in order to generate a schema-informed EXI encoding. So the above essentially rules out a large (possibly the majority) of XML content, and rules out valid EXI encodings. Again, 1) that seems very restrictive to justify a structured suffix; and 2) it reinforces the feeling that this registration may be in part motivated by some misunderstanding of EXI.


Thanks!

-- 
Robin Berjon - http://berjon.com/ - @robinberjon