W3C home > Mailing lists > Public > www-tag@w3.org > May 2009

RE: Versioning and HTML -- version indicators

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 15 May 2009 19:50:04 -0400
To: Larry Masinter <masinter@adobe.com>
Cc: "www-tag@w3.org WG" <www-tag@w3.org>
Message-ID: <OF96E9596B.E8F8CBF8-ON852575B7.0081921C-852575B7.0082BD5A@lotus.com>
Larry, this is a good analysis, I think.  A few details I'd quibble with, 
but overall it's very helpful.  I would be curious for your comments on 
the TAG blog entry I wrote awhile back. [1]

In particular, I still tend to believe that:

"If the same document means different things in different versions of a 
language, then it's very important to indicate which version the author 
had in mind when creating the document. Putting that version indicator 
into the document itself is one good way to do it."

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."

The phrase "all versions of a specification" is shorthand:  in general, a 
receiver knows either a priori or from an explict indicator like a mime 
type >something< about which specifications might apply to interpreting a 
document, but we're concerned with the case where the receiver is unsure 
which of several versions of the specification the sender might have used. 
 Indeed, the receiver may or may not know about all of the versions of the 
specification that are in use by senders.  If the document has at most one 
legal meaning per any of the specifications the sender >might< have used, 
then no version indicator is needed for correct interpretation.  A 
receiver will either interpret the document correctly, or decide that it 
cannot decode it.  Having an in or out of band version identifier would 
not cause it to behave any differently, except perhaps to provide clearer 
diagnostics.

Even if one continues to try to use explicit indicators, I think the blog 
entry raises some intersting questions as to what the value of a version 
indicator should be in cases where a given document can in fact be 
interpreted properly per several versions of the specification (e.g. the 
recipe example).  Until that's clarified, I think it's hard to advocate 
for explicit indicators.

I would actually propose that, with respect to explicit version indicators 
in particular, we take the points in the blog entry as a starting point, 
and either publicize them, elaborate them, or where necessary correct 
them.  To me, they look right as far as they go.

Noah

[1] http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Larry Masinter <masinter@adobe.com>
Sent by: www-tag-request@w3.org
04/28/2009 08:48 AM
 
        To:     "www-tag@w3.org WG" <www-tag@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: Versioning and HTML -- version indicators


Version indicators

Version indicators can either be out-of-band (not within the content,
but associated with the content, such as with using file extensions,
MIME types or other indicators) or in-band (contained in the content),
or some combination (out-of-band information overriding in-band or
vice versa, or combined in some other more complex way.)

In-content version indicators can either be global (readily determined
by reviewing the content in a fixed location or within the head
1k bytes of the file, for example) or local.

Languages can change through augmentation (adding new keywords,
features, procedures, available combinations) restriction 
(previous options are deprecated, removed, disallowed),
clarification (previously  ambiguous features clarified) or
changed incompatibly in some or all circumstance.

Augmentations increase the set of strings that are valid
or meaningful or useful instances in the language, restrictions
decrease the set. Clarifications generally leave the set
alone, while incompatible changes may or may not modify
the set.

Whether language changes can be recognized without version
indicators depends on the type of change:

Some augmentations might be recognized by appearance
of syntax that wasn't previously recognized (i.e., the
"version indictor" is the use of the feature itself).

Augmentations might be ignored or merely processed incorrectly
by old implementations rather than being recognized as
intended with a formerly unimplemented interpretation.

Restrictions, clarifications, incompatible changes cannot
readily be determined by scanning, though. 

Even though it is possible to avoid having out-of-band
or global-scope version indicators for augmentations, 
this does not mean that there are no advantages or uses
for in-band global indicators.

If there are multiple languages (whether Algol 60 vs Algol 68
or just multiple "modes", having a global-scope in-band
version indicator allows for switching between one interpreter
and another. Indicating the version in-band but requiring
parsing of the content means that it isn't possible to
evolve syntax or parsers.

Larry
-- 
http://larry.masinter.net
Received on Friday, 15 May 2009 23:48:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:13 GMT