versioning, robustness principle, doctypes etc

Larry Masinter wrote:
> Conformance checks can use a version indicator (doctype for example)  
> to determine which conservative advice should be applied.

Having an in-band version indicator for conformance checking makes the  
following unwritten 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.)

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

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

  * 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).

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

* Henri Sivonen wrote:
Your assumptions are based on the assumption that conformance to some
version is somehow different to conformance to a different version from
the perspective of a conformance checker. Otherwise there could not be
good advice and bad advice, only correct and incorrect "advice", and
there would be no "target version" to consider. I would regard this as
incorrect, and hence your assumptions as not implied by inline labels.

The notion of a "target version" is particularily problematic. If you
consider the inline label, or the user's choice, as necessarily correct,
there are cases where the checker could not report that the only thing
preventing a resource passing its checks is the "target version", and
it would instead generate plenty of rather meaningless errors that'd
be better reported by a dedicated tool (like one designed to aid you in
switching from one version to another).
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

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

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

On Aug 10, 2009, at 13:34, Bjoern Hoehrmann wrote:


I'm assuming that if language level n+1 makes something non-conforming  
that was conforming in language level n, the newer spec does so for a  
good reason. If people have language level n version identifiers in  
their documents, they miss out on this important advice.

Basically if current wisdom is that <font> is evil, <font> doesn't  
become less evil if you add an HTML 4.01 Transitional doctype.

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

On Aug 17, 2009, at 04:51, Larry Masinter wrote:

OK.

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

I'm not assuming that. What I assuming is that if the newer language  
makes old language features non-conforming, the old language features  
are bad right away.

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

Good point. However, if the use case is targeting old consumers, the  
validation target should be determined by the feature set of old  
consumers--not by the feature set of an old spec. They don't  
necessarily match. It's mostly fiction that consumer version x  
implements language version n entirely and x+1 implements n+1 entirely.

> I mentioned "conformance checker", but of course, the utility
> of version indicators is also good for editors,

More on this below.

> translation gateways,

How? Why wouldn't translation gateways want to be as versionless as  
browsers?

Also, I'd argue that standalone translation gateways as a product  
category are being obsoleted by Opera Mini on one hand and full  
browser engines on mobiles (e.g. Fennec and Mobile Safari) on the other.

> compatibility filters,

What are compatibility filters?

Standard syntax works only to the extent the validation targets are  
standard. If you want to validate to a subset of the official language  
so that the subset fits your CMS, it doesn't matter much if place  
where you put the identifier is standard if the identifier is not.  
(Consider <html version="my-cms-subset-of-html5">.)

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Henri Sivonen writes:

>> * Henri Sivonen wrote:
>>> Having an in-band version indicator for conformance checking makes
>>> the
>>> following unwritten 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.)
. . .
>
> I'm assuming that if language level n+1 makes something non-conforming
> that was conforming in language level n, the newer spec does so for a
> good reason. If people have language level n version identifiers in
> their documents, they miss out on this important advice.
>
> Basically if current wisdom is that <font> is evil, <font> doesn't
> become less evil if you add an HTML 4.01 Transitional doctype.

_This_ assumes that the semantics of version identifiers is "All
consumers of this document should behave as if they were operating
with respect to the named version."  The semantics that I would like
to see, and which I believe is what others arguing for the utility of
an optional version identifier would agree with, is "This document was
authored with the named version in mind -- consumers take note."  The
latter interpretation is entirely consistent with a conformance
checker saying

 "1) Conformant to V[specified];
  2) Features xxx and yyy of V[specified] are now deprecated -- see
     [appropriate migration information]"

ht
- --
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@...
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFKoSbRkjnJixAXWBoRAjz4AJ0V3IDBzQoCnZzCeg6OgWUkqk7LZwCeMNtd
q46OMEbc7RyjIqA2i42IIkg=
=sDlQ
-----END PGP SIGNATURE-----

Henri Sivonen writes:

> I'm not assuming that. What I assuming is that if the newer language
> makes old language features non-conforming, the old language features
> are bad right away.

Why is this true in all interesting cases?  Example:  someone deploys a
language for which keyword are treated as case-insensitive, so xxx, Xxx,
xXx, and XXX are the same.  Over time, for whatever reason, it's decided
that this variability is a bad thing.  So, users are warned, and
eventually a new version of the language is introduced that mandates, say,
lowercase only.  Per this new version of the language, all except the
first of the above identifiers are illegal, or if you prefer, undefined.
Let's imagine, though, that in filesystems, databases, and/or web servers
around the world there live lots of documents written to the old
specification.  Why is their use of the old feature (in this example the
upperase or mixed case keywords) "bad right away"?  Whether or not inband
version identifiers are used to help sort things out, I don't think those
old documents need immediately be treated as "bad".   Software can still
process them and indicate:  you seem to have used a feature that was
discontinued as of version N; I can continue or choke as you prefer.

I should say that I am not arguing in favor of Larry's broader point of
encouraging in-band identifiers, on which I stand somewhere betwen neutral
and against.  I'm just curious about the quote above, which seems to rule
out lots of changes that people do make from time to time when evolving
languages.

FWIW, my own thinking on in-band version ids is:  if the same content is
ever going to mean two incompatible things per different definitions of
the language, e.g. if version one says {0=false, 1=true} and version two
says {1=false; 0=true}, then some sort of version indicator in the
document is useful to disambiguate the intended interpretation.  In all
other cases version identifiers are redundant, as without them one either
properly understands the document, or realizes that features are used that
are not understood (we can't tell if they are outright errors, or just
features from a different version of which we are unaware).  Larry seems
to believe that even in some of these cases, the inband ids provide enough
value to authoring tools and the like that they are worth the costs (I.e.
the cost of specifying the correct use of the ids, providing tooling to
insert the ids, perhaps writing validators to check that content in the
document is indeed consistent with the ids, teaching users how to use the
mechanism, etc.)  As I say, I am somewhere between unconvinced and leaning
against.

Noah

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








Henri Sivonen <hsivonen@...>
Sent by: www-tag-request@...
09/04/2009 10:36 AM
 
        To:     Larry Masinter <masinter@...>
        cc:     "www-tag@..." <www-tag@...>, (bcc: Noah
Mendelsohn/Cambridge/IBM)
        Subject:        Re: versioning, robustness principle, doctypes etc


On Aug 17, 2009, at 04:51, Larry Masinter wrote:

OK.

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

I'm not assuming that. What I assuming is that if the newer language
makes old language features non-conforming, the old language features
are bad right away.

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

Good point. However, if the use case is targeting old consumers, the
validation target should be determined by the feature set of old
consumers--not by the feature set of an old spec. They don't
necessarily match. It's mostly fiction that consumer version x
implements language version n entirely and x+1 implements n+1 entirely.

> I mentioned "conformance checker", but of course, the utility
> of version indicators is also good for editors,

More on this below.

> translation gateways,

How? Why wouldn't translation gateways want to be as versionless as
browsers?

Also, I'd argue that standalone translation gateways as a product
category are being obsoleted by Opera Mini on one hand and full
browser engines on mobiles (e.g. Fennec and Mobile Safari) on the other.

> compatibility filters,

What are compatibility filters?

Standard syntax works only to the extent the validation targets are
standard. If you want to validate to a subset of the official language
so that the subset fits your CMS, it doesn't matter much if place
where you put the identifier is standard if the identifier is not.
(Consider <html version="my-cms-subset-of-html5">.)

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

On Sep 15, 2009, at 04:52, noah_mendelsohn@... wrote:

> Henri Sivonen writes:
>
>> I'm not assuming that. What I assuming is that if the newer language
>> makes old language features non-conforming, the old language features
>> are bad right away.
>
> Why is this true in all interesting cases?

Presumably specs shouldn't make old language features non-conforming  
unless the old features are bad. I can see a point that <font> has  
always been bad but it couldn't be made non-conforming until CSS was  
available to authors. However, I'd argue that when something is made  
non-conforming because it's bad and there's a less bad replacement,  
the worse thing shouldn't be made non-conforming until the replacement  
has been deployed.

(In the case of Web languages, you almost always don't have the  
liberty to update a language in a way that makes a previously defined  
thing be processed as undefined.)

> Let's imagine, though, that in filesystems, databases, and/or web  
> servers
> around the world there live lots of documents written to the old
> specification.  Why is their use of the old feature (in this example  
> the
> upperase or mixed case keywords) "bad right away"?

If variability is bad and non-variability was already allowed under  
the old spec, the old documents could have been authored in a way that  
is now declared the non-bad way. Why wasn't it bad back when the old  
documents were authored to have the variability? Or the other way: If  
variability is bad, why would it be less bad depending on when the  
content was authored?

On the other hand, if that variability isn't bad enough to warrant an  
error, the new spec shouldn't say variability is bad to the point of  
being an error.

There are cases when old practices are very, very mildly bad so that  
it's both wasteful to edit old content to remove the practices and  
it's wasteful to keep using the practice for new documents. For  
example, specifying the type="text/css" attribute on the HTML <style>  
element is this kind of practice--specifying the attribute is just  
waste of typing, network bandwidth, parsing time and maintainer's  
reading attention. I think in cases like this, the waste of fixing old  
but maintained stuff should outweigh fighting the prospective waste  
and the practice shouldn't be proclaimed as an error, although it  
would be appropriate to communicate the prospective wastefulness to  
authors in other ways.

> Whether or not inband
> version identifiers are used to help sort things out, I don't think  
> those
> old documents need immediately be treated as "bad".   Software can  
> still
> process them and indicate:  you seem to have used a feature that was
> discontinued as of version N; I can continue or choke as you prefer.

In practice, Web language consumers have an incentive not to choke if  
they maintain a non-choking code path anyway, so it's useless for  
specs to give them an opportunity to continue or choke depending on  
version identifier. Thus, consuming software using a version  
identifier to sabotage itself is not a useful motivation for having  
version identifiers.

(The incentive is this: UA A implements language as of version N-1 and  
doesn't choke on feature F. UA B implements language versions N-1 and  
N but doesn't choke on feature F if content specifies N-1 but chokes  
when content specifies N. When content specifies N but uses feature F  
nonetheless, UA A seems to work better from the user point of view  
that UA B. Thus, UA B disadvantages itself by implementing conditional  
choking.)

> FWIW, my own thinking on in-band version ids is:  if the same  
> content is
> ever going to mean two incompatible things per different definitions  
> of
> the language, e.g. if version one says {0=false, 1=true} and version  
> two
> says {1=false; 0=true}, then some sort of version indicator in the
> document is useful to disambiguate the intended interpretation.

This situation is contrived and doesn't arise in well-maintained Web  
languages. If a working group tried to update a Web language in such a  
gratuitously incompatible way, the community would flip the bozo bit  
on the spec and the WG and ignore them, so the specified  
incompatibility wouldn't have a bearing on practical matters. Thus,  
gratuitously incompatible changes aren't a useful motivation for  
having version identifiers.

(Besides, we could leave it to the hypothetical reckless future WG to  
define a version identifier if/when they make such an incompatible  
change. After all, consuming software developed now wouldn't be able  
to guess what incompatibility a new version identifier means and  
they'd keep on processing the content anyway due to the self-sabotage  
disincentive outlined above.)

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

Le 17 sept. 2009 à 03:18, Henri Sivonen a écrit :
> Presumably specs shouldn't make old language features non-conforming  
> unless the old features are bad.

A feature was not necessary bad in the past, but appropriate for a  
specific historical, cultural or technological context.

> I can see a point that <font> has always been bad but it couldn't be  
> made non-conforming until CSS was available to authors. However, I'd  
> argue that when something is made non-conforming because it's bad  
> and there's a less bad replacement, the worse thing shouldn't be  
> made non-conforming until the replacement has been deployed.

It seems reasonable but difficult to properly estimate. Deployment is:

* available in a specification?
* implemented in a product? a majority of products? (then issues with  
threshold and metrics)
* used in many Web pages (how do we measure that? Specifically if the  
rate for content replacement is low)


> (In the case of Web languages, you almost always don't have the  
> liberty to update a language in a way that makes a previously  
> defined thing be processed as undefined.)

why?


> Or the other way: If variability is bad, why would it be less bad  
> depending on when the content was authored?

Usage changed.


> For example, specifying the type="text/css" attribute on the HTML  
> <style> element is this kind of practice

not a good example:

> --specifying the attribute is just waste of typing,

* geeks authoring content by hands (with usually shortcuts)
* templates designers
* authoring tools implementers

The vast majority does not type it.

> network bandwidth,

… very specific cases, which are far, far, far away from the business  
reality of common web sites.

> parsing time

nothing compared to rendering

> and maintainer's reading attention.

?


> If a working group tried to update a Web language in such a  
> gratuitously incompatible way, the community would flip the bozo bit  
> on the spec and the WG and ignore them, so the specified  
> incompatibility wouldn't have a bearing on practical matters. Thus,  
> gratuitously incompatible changes aren't a useful motivation for  
> having version identifiers.

Or if the technology is becoming overly complex because it can't  
reinvent itself and become a babel tower, it will collapse. The issue  
as I see it in this discussion is often painted as right or wrong more  
than a share of benefits and issues on both sides of the argument.

For example for html5 versus html4, I know that having a version  
identifier is (in the current state of the specification) a must. The  
meaning of some elements (without thinking about processing) have been  
changed. And if you receive a document from a source you are trusting,  
without version identifier, it becomes hard to know which definition  
of the elements you refer to.




--
Karl Dubost
Montréal, QC, Canada