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 19:23:42 -0700
To: Henri Sivonen <hsivonen@iki.fi>
CC: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <8B62A039C620904E92F1233570534C9B0118DB6E16A1@nambx04.corp.adobe.com>
I had another thought -- that the main disconnect in the 
conversation so far is that we both really failed to
distinguish between "language as used" and "language
as specified" when talking about "conformance checking".

The word "conformance" is partly what throws off the
discussion. Typically, there are two kinds of checking
that are valuable: "usage checking": will this instance
of the language actually run or be compatible with software
that is (or is likely to be) widely deployed, and
actual "conformance checking" which is a much narrow
definition of "does this instance of the language
match this particular version of the document as
specified".

In theory, one might hope that if you do a really good
job of writing the specification and everyone implements
the specification exactly, that "usage checking"
and "conformance checking" will be the same. But
in practice, implementations vary, have limits,
don't implement the spec exactly, or the spec has
errors or misunderstandings or ambiguities. In any
case, both kinds of checking are useful.

For "usage checking", though, a version indicator
doesn't help as much, unless the deployed software
consistently exhibits different behavior with 
different version indicators.

I think "conformance checking" is useful; a software
product that offers "checking" would probably offer
both conformance and usage checking. If deployed
language interpreters *mainly* follow the specifications,
then usage checking could be implemented by
doing conformance checking and adding additional
constraints or loosening requirements as necessary.

I have the feeling that having "conformance checking"
as well as "usage checking" is an important element
toward encouraging the two to be the same, i.e.,
implementations for which a positive conformance 
check is a good motivation for making sure that
the usage check doesn't have to be more restrictive.
I think the analysis of that relationship will require
a little more thought, but I wanted to update my
previous note.

Larry
--
http://larry.masinter.net


-----Original Message-----
From: Larry Masinter 
Sent: Sunday, August 16, 2009 6:52 PM
To: 'Henri Sivonen'; www-tag@w3.org
Subject: RE: versioning, robustness principle, doctypes etc

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


> 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,
http://en.wikipedia.org/wiki/List_of_HTML_editors
and yes, of course, each could use a product-specific in-band
syntax like the Emacs code line to communicate the validation
target.

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.

Regards,

Larry
-- 
http://larry.masinter.net
Received on Monday, 17 August 2009 02:24:28 GMT

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