RE: Versioning and HTML

(catching up on back email)

I have much more reluctance about the use of explicit version indicators 
than Larry seems to (see, e.g. [1]), but I think Larry's note [2] is a 
wonderful, cogent analysis of the reasons that languages evolve, sometimes 
"incompatibly".  In particular, I think this is a note that we in the TAG 
should consider as very useful motivation as we consider our next steps on 
versioning.

Noah

[1] http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html
[2] http://lists.w3.org/Archives/Public/www-tag/2009Apr/0063.html

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








Larry Masinter <masinter@adobe.com>
Sent by: www-tag-request@w3.org
04/25/2009 08:25 PM
 
        To:     Ian Hickson <ian@hixie.ch>
        cc:     "www-tag@w3.org WG" <www-tag@w3.org>, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        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 Tuesday, 26 May 2009 14:36:43 UTC