W3C home > Mailing lists > Public > public-xml-er@w3.org > March 2012

Re: Deployment and media types

From: Robin Berjon <robin@berjon.com>
Date: Fri, 2 Mar 2012 14:33:35 +0100
Cc: public-xml-er@w3.org
Message-Id: <56E9B220-BD2C-4533-B6F7-FB902A60CC51@berjon.com>
To: Mark Baker <distobj@acm.org>
On Feb 29, 2012, at 18:25 , Mark Baker wrote:
> IMHO, we can't do both...
> I don't believe that RFC 3023 can apply to XML-ER content, either for
> the existing */xml and */*+xml types, or even any future */*+xml
> types, as all of those indicate to a message recipient that the
> document can be processed by an XML 1.0 processor in order to realize
> "generic processing";
>  When a new media type is introduced for an XML-based format, the name
>  of the media type SHOULD end with '+xml'.  This convention will allow
>  applications that can process XML generically to detect that the MIME
>  entity is supposed to be an XML document, verify this assumption by
>  invoking some XML processor, and then process the XML document
>  accordingly.
> -- RFC 3023 sec 7

Wait  I'm confused. Isn't the primary purpose of media type RFCs to be wilfully violated? What are we doing wrong?

More seriously: introducing a new media type (or suffix) is too costly and does not solve the problem of usefully processing existing broken XML content, so it's not an option. I suspect that we will in fact need to update RFC2023 at some point, but that we won't know just how exactly to update it before we have enough hindsight on the effect of introducing XML-ER in the ecosystem. Since I don't see it having any serious interoperability implications, I don't think that it's a problem for the media type registration to be behind the times for a few years.

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

Coming up soon: I'm teaching a W3C online course on Mobile Web Apps
Received on Friday, 2 March 2012 13:34:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:47:26 UTC