Re: Deployment and media types

Hmm...  I am loathe to introduce a new media type at this point.  It 
makes deployment of this piece of the toolchain even more difficult.  In 
my mental model of how an XML-ER processor hooks in, if there is a 
problem with generically processing XML I *could* hand it to an XML-ER 
processor to try to fixup the content and get it BACK to generic XML so 
I can then push it down the chain.  In that use model, I am performing 
additional processing on documents that I would otherwise have been 
unable to process in the hopes of gleaning something intelligible from 
them.

Perhaps others have other goals for XML-ER - that's mine.  It is not 
"lofty".

On 2/29/2012 11:25 AM, Mark Baker wrote:
> 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
>    accordingly.
>   -- 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.
>
> Thoughts?
>
> Mark.

-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.
+1 763 786 8160 x120

Received on Wednesday, 29 February 2012 17:50:50 UTC