- From: Larry Masinter <masinter@adobe.com>
- Date: Sat, 25 Apr 2009 17:34:43 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: "www-tag@w3.org WG" <www-tag@w3.org>
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