RE: Versioning and HTML

Another use case for embedded version indicators is to track versions
during authoring, production and deployment before they are sent over
the wire.  Authors and authoring tools may well know which version of
a language they are editing or producing content for, which features
they are assuming and so forth. Without any way of marking the intended
version in the content itself, it is likely that version indicators will
be carried outside, and subject to loss. As has been seen with MIME types,
external metadata is subject to risks of separation, lack of control
by authors on deployment separation.

Right now, new HTML features seem to be deployed on the web by advanced
cites "sniffing" the User Agent version string and using it to determine
which version of a HTML page should be generated. This process is subject
to some significant failures, mainly because new or otherwise unrecognized
servers have no way of indicating to such sniffers that they, too, intend
to interpret the same features as one or another proprietary browser.

So I think we need to consider the use cases of language version management
during pre-publication processes, and also the use case of "browser version"
sniffing and the failure cases. This touches on the "content negotiation"
issue (as the sub-case of negotiating versions should be in scope for
the versioning discussion.)

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


-----Original Message-----
From: Larry Masinter 
Sent: Saturday, April 25, 2009 12:06 PM
To: 'Ian Hickson'
Cc: 'www-tag@w3.org WG'
Subject: RE: Versioning and HTML

I'm trying to lay out some of the general reasons for "why languages
evolve and why we need versions" with the specifics for HTML.


On Sunday, April 19, 2009 Ian Hickson wrote:
>> Problem (from Chris Wilson): "the general problem with how we define
>> HTML today; if HTML5 becomes a Rec and we realize we did something
>> poorly we will cause rampant compatibility problems if we change
>> implementations. There are a whole bunch of versioning mechanism that
>> will address that but also cause their own problems."
>
>Isn't this the problem the Candidate Recommendation stage is supposed to
>address?

In the history of computer science, I can think of no language that has
not evolved, been extended, or otherwise "versioned" as long as the
language has been in use.  This applies to network protocols, character
encoding standards, programming languages, and certainly to every known
technology found on the web.

And I can think of no cases where a language hasn't gone through at least
some minor incompatible change.

The standards process is established as a way of evolving specifications
and implementations in a way to reduce the likelihood of complete failure
to interoperate, but certainly not to guarantee that no incompatible
changes will be needed in the future.

Reasons why Languages (and HTML in particular) will need changes in the
future:

1:requirements change: a. New contexts b. competitive pressure
2: two implementations aren't represenative
3: ambiguiies appear


1: Requirements change: This is the main reason for evolution of
languages -- people want the language to support some new feature
that hadn't been thought of at the time of the original language
design. Often requirements can be accommodated without actually 
changing the behavior of anything else, but at times, something 
resembling a "version" is necessary.

1.a. Requirements can change because of environmental changes -- newer
hardware platforms, operating systems, user interface devices,
and so forth.

1. b. Requirements can change because of competitive pressures -- there are
features in some other competitive "language" that seem desirable
enough to want to evolve the language without making it unreasonably
complex.


What future technologies might appear? 3D browsers? Non-WIMP devices?
For HTML, by the current specification has only primarily 
considered the needs of "browsers" which have "windows" and something
one can "click" with, a typist, the notion of being able to enter forms,
the idea that the "web page" is being displayed on a two-dimensional
device with rectangular layout, that there is a single "user", and so
on and so forth. Who knows whether these constraints are necessary.

Is there some merger of web and messaging and conferencing that would
work better with highly desirable changes to HTML5? With what confidence
can you say "no"? What is the cost of providing for incompatible changes
against the risk of chaos if they begin to appear?

2. Two implementations aren't representative

"Candidate Recommendation" exit criteria only needs two implementations,
and does not even require spanning the breadth of applicable hardware
and software. 

Can HTML5/CSS3 work well on an electronic paper display such as Kindle?
Can it work well in a collaborative multi-pointer system?
Is there a single "focus" or "tab order"? Does it work well with
typical "remote control" devices used for TVs? These are current
platforms which are not required to work well, in order to exit CR.

3. Ambiguities appear

This is another common reason why languages evolve. Implementors get
together and write a specification. They're happy because the spec
matches what they implement -- or so they think!

However, all of the implementors were part of the spec development
process and .... amazingly .... there are some things they know and
agree on that aren't part of the spec. (No matter how brilliant and
wise the spec editor). 

Later, someone else comes along and implements the spec as written, but,
either because of confusing wording or missing information, their
implementation is incompatible. Then there's a desire to update the
spec to resolve the ambiguity, but there is no way for authors to
create material that acknowledges that the author has chosen the
new (unambiguous) definition over the previous (ambiguous) one.


I'm sure there are other reasons for language evolution and there's
some overlap between these, but I thought this might help in
elaboration of the versioning framework. 

Thoughts? 

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

Received on Sunday, 26 April 2009 00:35:29 UTC