Re: versioning, robustness principle, doctypes etc

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@iki.fi>
Sent by: www-tag-request@w3.org
09/04/2009 10:36 AM
 
        To:     Larry Masinter <masinter@adobe.com>
        cc:     "www-tag@w3.org" <www-tag@w3.org>, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        Re: versioning, robustness principle, doctypes etc


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

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

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?

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

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@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 15 September 2009 01:53:03 UTC