- From: David Orchard <dorchard@bea.com>
- Date: Tue, 22 May 2007 13:09:54 -0700
- To: "Jan Algermissen" <algermissen1971@mac.com>, <noah_mendelsohn@us.ibm.com>
- Cc: "Mark Baker" <distobj@acm.org>, "Marc de Graauw" <marc@marcdegraauw.com>, <mark@coactus.com>, "Marc de Graauw" <mdegraau@xs4all.nl>, <www-tag@w3.org>
Exactly. And, even more importantly, are the allowed variations in the language that are deemed to remain the same media type (ie extensions that must be ignored if unknown) defined in the first version so that a V1 consumer can process later versions of the language? Cheers, Dave > -----Original Message----- > From: Jan Algermissen [mailto:algermissen1971@mac.com] > Sent: Tuesday, May 22, 2007 12:58 PM > To: noah_mendelsohn@us.ibm.com > Cc: Mark Baker; David Orchard; Marc de Graauw; > mark@coactus.com; Marc de Graauw; www-tag@w3.org > Subject: Re: Media types and versioning > > > On 22.05.2007, at 19:06, noah_mendelsohn@us.ibm.com wrote: > > > > > Mark Baker writes: > > > >> I'm ok with the second part of that, but if a new version is > >> compatible, then a new media type shouldn't be required. > > > > Which begs the question, what do you mean by compatible? > > This could be rephrased to "what are the allowed variations > between two versions of a format if they are to remain the > same media type?". > > Has that ever been thought through? > > Jan > > > > Almost surely, a > > new version of a language will introduce both new syntax and > > corresponding new information conveyed by that syntax. So, in that > > sense, there's almost always some incompatibility when new > constructs > > are used. > > > > Sometimes the new information is in some sense orthogonal > to the old, > > allowing one to ask separately which pieces of the content are > > "understood". Sometimes, the new rules change the > implications of the > > old > > fields. For example, if the old version says that case doesn't > > matter > > for a field, and the new version of the language says that case > > matters, then even documents that were legal in the old > language may > > be taken to convey information that might not have been intentional > > when the document > > was authored. Even in the simple case where the new content is > > completely orthogonal syntactically and semantically, there is the > > question of whether users consider it OK to to ignore if it's not > > understood. > > > > For reaons like these, I don't think using the word "compatible" > > without > > explanation or qualification is appropriate. I do agree > that for some > > families of languages, one can define useful notion of > compatibility > > that make it appropriate to consider using a single media > type for all > > of the versions. I don't agree that those styles of language > > evolution are always what people want. > > > > -------------------------------------- > > Noah Mendelsohn > > IBM Corporation > > One Rogers Street > > Cambridge, MA 02142 > > 1-617-693-4036 > > -------------------------------------- > > > > > > > > > > > > > > > > > > "Mark Baker" <distobj@acm.org> > > Sent by: mark@coactus.com > > 05/18/2007 08:04 AM > > > > To: "David Orchard" <dorchard@bea.com> > > cc: noah_mendelsohn@us.ibm.com, "Marc de Graauw" > > <marc@marcdegraauw.com>, "Marc de Graauw" <mdegraau@xs4all.nl>, > > www-tag@w3.org > > Subject: Re: Media types and versioning > > > > > > On 5/17/07, David Orchard <dorchard@bea.com> wrote: > >> What about incorporating a version # in the media type? > >> > >> Say application/soap+1dot2+xml, etc. > > > > That's fine. On the ietf-types list, I think I've recommended > > something similar for at least one format which made backwards > > incompatible changes. > > > >> 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'm ok with the second part of that, but if a new version is > > compatible, then a new media type shouldn't be required. > > > > Mark. > > > > > > > >
Received on Tuesday, 22 May 2007 20:10:40 UTC