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

Deployment and media types

From: Mark Baker <distobj@acm.org>
Date: Wed, 29 Feb 2012 12:25:05 -0500
Message-ID: <CALcoZipx4ctBrLBZNCeNJmztAjB-aqczWtd1tvQf+Ch_PVcv4A@mail.gmail.com>
To: public-xml-er@w3.org
Hi everyone,

I joined the list after reading Jeni's message to www-tag. It was her
comment that nobody wanted to change the XML specification that piqued
my interest.  While I have long criticized XML for its draconian error
handling (or more specifically, the kinds of things it considers
errors) and general lack of streamability, I haven't seen any mention
in the discussion to date or in the draft spec, about how we plan to
*deploy* XML-ER. Specifically, how we're supposed to integrate it into
the Web stack in a manner that makes it both easy to use as well as
maximizes compatibility with existing standards and software.

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
 -- RFC 3023 sec 7

AFAICT, this means we'll need a new media type as well as a new
suffix, and moreover, new types for any format which uses a +xml type,
something along the lines of "application/xhtml+xmler". This will make
deployment relatively expensive, similar to the cost of deploying an
entirely new data format from the POV of users who can't use ".atom"
or ".xhtml" in file names since those map to *xml types. Data format
designers will also need to carefully weigh similar pros and cons when
deciding whether to base their work upon XML 1.0 or XML-ER.

Though I'm surely getting ahead of myself, even if we stick with
separate media types, there's still bound to be "leakage" where our
existing XML processing software will inadvertently receive - and
choke on - XML-ER content sent due to some invalid assumption by the
sender. I fear that this could become widespread given the general
lack of understanding of the important role of media types on the Web
by authors and developers.

So one hand I wanted to ask the seemingly innocuous question, "What
media type?", and on the other, I wonder if we really want to go down
this path.


Received on Wednesday, 29 February 2012 17:25:33 UTC

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