- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 22 May 2009 21:53:30 -0400
- To: Larry Masinter <masinter@adobe.com>
- Cc: Ian Hickson <ian@hixie.ch>, "www-tag@w3.org WG" <www-tag@w3.org>
(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