- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 22 May 2009 22:29:17 -0400
- To: David Booth <david@dbooth.org>
- Cc: Larry Masinter <masinter@adobe.com>, "www-tag@w3.org WG" <www-tag@w3.org>
David Booth writes: > Are you excluding cases where documents are stored? A document producer > can only know about versions that exist at the time when the document is > produced (or originally transmitted). But if the document is stored and > viewed much later, there may be newer versions of the language > specification by the time the document is consumed. Yes. I think this is no different than the "web services" case in which senders and receivers are updated on very different schedules, and may be out of sync by months or years. The point is, deciding on whether the language will evolve incompatibly is a commitment that you make and stick with, typically on day 1. That is, you make a commitment in advance that no future specification will ever give an interpretation to any legal document that is "incompatible" (see below)with that given by earlier specs. (Though of course, there may be documents that are legal only in later versions, as those will be safely rejected by old software.) When such a compatibility strategy is adopted, and I think Jonathan said the same thing, in band version indicators are not needed. Regardless of the version of the specification to which your software is written, you will either interpret a document correctly, or else realize that you must reject it (I.e. because you encounter syntax ruled out by your version of the spec). Now, for each language we can define what we mean by "incompatible interpretations". For example, some early versions of HTML interpret the <IMG> tag as legal, but to be ignored; later versions provide for use of these tags to embed images. Whether that represents the sort of incompatibility that should require the use of other, inband version indicators is a choice the designers of the earlier HTML specifications get to make. If we use explicit version indicators, then we have the chance to tell older browsers: don't even try to show this document if you don't understand the <img> tag. If we don't use explicit indicators, then we live with the fact that even older browsers will consider such tags legal, but will provide different renderings than newer ones. So, you have to decide which sorts of incompatibilities are ones that you want rejected outright. Depending on your choices, you may need to use explicit inband indicators of specification levels. Like Jonathan, I think that's a complexity best avoided when you can. Either way, I think the issues are more or less the same for long term document storage as for transmission between software applications updated at similarly long intervals. Noah -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- David Booth <david@dbooth.org> 05/18/2009 09:36 AM To: noah_mendelsohn@us.ibm.com cc: Larry Masinter <masinter@adobe.com>, "www-tag@w3.org WG" <www-tag@w3.org> Subject: RE: Versioning and HTML -- version indicators Noah, On Fri, 2009-05-15 at 19:50 -0400, noah_mendelsohn@us.ibm.com wrote: [ . . . ] > I also believe the converse: > > "If a given document never has more than one possible meaning when > interpreted per all versions of a language specification (though it may be > illegal per some of them), then neither in band nor out of band version > indicators are strictly needed." If the document is stored such that it may be viewed much later, then the original producer of the document would h Are you excluding cases where documents are stored? A document producer can only know about versions that exist at the time when the document is produced (or originally transmitted). But if the document is stored and viewed much later, there may be newer versions of the language specification by the time the document is consumed. David Booth
Received on Tuesday, 26 May 2009 14:36:26 UTC