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

RE: versioning, robustness principle, doctypes etc

From: Larry Masinter <masinter@adobe.com>
Date: Sun, 16 Aug 2009 18:51:42 -0700
To: Henri Sivonen <hsivonen@iki.fi>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118DB6E169E@nambx04.corp.adobe.com>
I wrote:
>> Conformance checks can use a version indicator (doctype for example)  
>> to determine which conservative advice should be applied.

And Henri replied:

> Having an in-band version indicator for conformance checking makes the  
> following unwritten assumptions:

No, it makes none of these assumptions.

>  * It's appropriate for a person opting to target an older "version"  
> not to see more up-to-date advice. (Surely newer advice should be  
> assumed to be better informed and, thus, better advice.)

No, there is no such assumption. Your complaint seems to make
the odd assumption that "newer advice" is uniform, i.e., that
versions of languages are somehow uniformly and instantaneously
deployed. But that is not the case; at any instant in time, there
will often be many different versions of any language 
deployed. Of course, it is also possible for a conformance checker
to be asked to override the in-band version indicator, and
check conformance against any other version desired.

If a newer specification is less conservative than an older
one then the "newer advice" is not always "better informed"
if the goal is to target older consumers.

>  * If the person running a conformance checker and the person  
> producing the markup are different people (or the same person at  
> different times), the markup producer should choose the checker target  
> "version"--not the person invoking the checker.

No, there is no such assumption. "can use" does not constrain
a conformance checker from also checking against any other
version the operator of the conformance checker wants.

I mentioned "conformance checker", but of course, the utility
of version indicators is also good for editors, translation
gateways, compatibility filters, and other devices that operate
as if they are "conformance" checkers but have no human

> Have you compared the model with an in-band spec version number based  
> version indicator against the following models?

I gave several reasons for why in-band version indicators
are useful, not only the "conformance checker" use case.

>  * The user of the conformance checker choosing the validation target  
> (i.e. out-of-band indication of the wanted profile).

>   * The user of an editor that embeds a conformance checker using  
> product-specific in-band syntax (consider the Emacs mode line) to  
> communicate the validation target, and the target choice may be more  
> granular than W3C spec versions (making the in-band indicator non- 
> interoperable).

Almost anything can be left to be "product-specific", including
elements of the language itself. We're engaged in standards making
to try to come to a common way that multiple, independent implementations
can use a common standard.

There are probably 100 different HTML editors in common use,
and yes, of course, each could use a product-specific in-band
syntax like the Emacs code line to communicate the validation

But there are more HTML editors in common use than there are
"major browsers". A standard that allows interoperability among
them is better than one that is not.


Received on Monday, 17 August 2009 01:52:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:30 UTC