RE: Versioning and HTML -- version indicators

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