RE: suggestion re: media type registration

I would offer that there is little technical difference between
   application/vnd.w3c.*+xml
and
   application/*.xml

However, there are major practical issues.  First, for there to be ANY value to the registration, there needs to be a registrar.  Otherwise, there is no likelihood of interoperation.

Second, since the registration would be in the vnd tree, it is up to the W3C to maintain, publish, and control the registry.  That is a problem (beyond the organizational problem of the W3C maintaining a registry) in that Joe Random programmer somehow needs to know to look someplace in the W3C for what registration to use or what a particular value means.

Third, one could easily envision someone in the IETF publishing application/mumble+xml and someone in the W3C publishing application/vnd.w3c.mumble+xml, where they have totally different semantics.  Yes, that is theoretically OK, because they are, by definition, different registrations.  However, most people expect a mumble to be a mumble...

Fourth, and conversely to the third, one could envision someone in the W3C publishing application/vnd.w3c.foo+xml.  Later on, it becomes of value to everyone, so it would make sense registering application/foo+xml in the IETF tree.  However, we then end up with two registrations for the same thing.

On a separate topic, I would strongly suggest AGAINST putting everything under application/xml.  One of the whole points of the MIME type system is that a user agent can make intelligent choices about objects WITHOUT examining the object itself.  If we went the application/xml route, user agents would have to parse the XML to figure out the namespaces, for example.  That can be an undue burden on applications.

> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Sun, September 14, 2003 11:01 AM
> To: public-ietf-w3c@w3.org
> Subject: Re: suggestion re: media type registration
> 
> 
> 
> murata@hokkaido.email.ne.jp (MURATA Makoto) writes:
> >On Fri, 12 Sep 2003 13:56:45 -0700 "Roy T. Fielding"
> ><fielding@apache.org> wrote:
> >
> >> As for the +xml types, a more effective mechanism would 
> have been to
> >> define a major type of xml under the namespace control of W3C, or
> >> barring that an xml tree (application/xml.soap) which could either
> >> be assigned to the W3C or at least incorporate the W3C 
> process. That
> >> would, of course, require an RFC to set up.  The +xml suffix seems
> >> to beg for the most delays.
> >
> >Non-W3C organizations (e.g., OASIS and ISO/IEC) create XML-based
> >languages and they may want to register specialized media 
> types. Thus,
> >I think the registration process should not be controlled by W3C.  
> 
> I'm not sure what Roy means by "namespace control of W3C" here, and
> would appreciate clarification.
> 
> He may be suggesting that no MIME content types beyond application/xml
> are needed for XML documents, as XML processors can use namespace
> information to differentiate which application should get which chunk
> of XML information, and additional information in the MIME 
> content type
> would be superfluous.
> 
> While I disagree with this view in the current circumstances, it is
> certainly coherent - but under no one's control in 
> particular.  I'm not
> sure what the W3C would want to add to the current namespace process,
> but suspect that "control" would go over badly with the many
> organizations beyond the W3C which are in the business of creating XML
> vocabularies for public use.
> 
> As for this:
> >> barring that an xml tree (application/xml.soap) which could either
> >> be assigned to the W3C or at least incorporate the W3C process.
> 
> It is my understanding that the W3C itself is unwilling to manage
> directly any kind of kind of registration system, and that URIs are
> supposed to resolve these kinds of problems without the need for
> centralized control.
> 
> >>The convention application/vnd.w3c.*+xml makes much more sense
> >>to me.
> 
> To me as well.
> 
> 
>

Received on Sunday, 14 September 2003 12:29:38 UTC