RE: Media types and versioning

What about incorporating a version # in the media type?  

Say application/soap+1dot2+xml, etc.

Then say in the media type definition that by definition any minor
version change is compatible, and any incompatible change will be
accompanied by a major version change.  

I have a feeling that the dispatch on the version # is actually done
later than the media type dispatch though.  Namely that each media type
stack handles the multiple versions.

Cheers,
Dave

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of noah_mendelsohn@us.ibm.com
> Sent: Thursday, May 17, 2007 12:22 PM
> To: Mark Baker
> Cc: Marc de Graauw; Marc de Graauw; www-tag@w3.org
> Subject: Re: Media types and versioning
> 
> 
> Mark Baker writes:
> 
> > I think that your problem could be solved simply by minting a new 
> > media type when you break backwards compatibility.
> 
> I can see the advantages, but I think there are also 
> disadvantages.  First of all, certain languages go through 
> many, many revisions that are at least in some ways 
> incompatible.  It's not clear to me that as a practical 
> matter the media type system is administered to handle the 
> repeated registrations that would follow from your 
> suggestion, and I'm also not convinced that the syntax of 
> media type identifiers is sufficiently flexible to do this 
> well.  Which leads to my 2nd point:  compatibility is in many 
> cases a matter of degree, and often applications want typing 
> mechanisms that help with negotiating specific aspects of 
> compatibility. 
> So, in the somewhat different world of Java, one does indeed 
> mint a new class name whenever one implements a new variant 
> of a class definition (very roughly analagous to a media type 
> in this story), but Java also provides the "interface" 
> abstraction, by which a new class can say "I 
> remain compatible with old conventions I1, I2, etc.").   The 
> closest we 
> seem to get with media types is the application/xxxx+xml 
> convention, where a new language can say "but I remain 
> compatible with xml".  That seems a bit limited.  So, I think 
> what's happening in practice is that people are minting and 
> deploying new media types when, on balance, the disruption 
> caused by publishing under the new type is deemed the lesser 
> evil compared to any downsides of publishing the new content 
> under the old media type (e.g. deploying HTML that provides a 
> specific semantic for a tag that would have been ignored in a 
> previous version of HTML). 
> 
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> "Mark Baker" <distobj@acm.org>
> Sent by: www-tag-request@w3.org
> 05/16/2007 11:16 PM
>  
>         To:     "Marc de Graauw" <mdegraau@xs4all.nl>
>         cc:     "Marc de Graauw" <marc@marcdegraauw.com>, 
> www-tag@w3.org, 
> (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        Re: Media types and versioning
> 
> 
> 
> On 5/16/07, Marc de Graauw <mdegraau@xs4all.nl> wrote:
> > Mark Baker:
> > > AFAICT, that's more or less what happens in the existing Web
> > > architecture.  HTTP messages carrying a document also 
> normally include
> > > a media type, which is essentially a name for a series of 
> compatible
> > > versions (e.g. "text/html" as a shortcut for HTML 2 + 3.2 
> + 4.01 + 5
> > > etc..).
> >
> > Yes, but the list is not explicit, so it is not possible to exclude
> > versions (you cannot say: do not process if your version is 
> lower than
> > 4.01). That is not necessary for HTML, but for other languages (like
> > medication, which example I use in my XML.COM article) it 
> often is, and
> > that is the mechanism I wanted to describe in my article.
> 
> I think that your problem could be solved simply by minting a new
> media type when you break backwards compatibility.
> 
> Mark.
> 
> 
> 
> 
>

Received on Thursday, 17 May 2007 21:27:12 UTC