- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 3 Jan 2010 10:38:23 -0800
- To: Larry Masinter <masinter@adobe.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
I don't really understand the change proposal process, so apologies if responding to this email is not the proper way to provide feedback. Your proposal seems to have two main points: 1) Having a more flexible DOCTYPE allows for polyglot documents that need to conform to two different syntaxes. 2) Having a more flexible DOCTYPE would help future-proof the spec in case we want to add a version identifier in a future, incompatible version of the specification. I don't really have an opinion about (1), but (2) doesn't make much sense (details below). On Sat, Jan 2, 2010 at 4:21 PM, Larry Masinter <masinter@adobe.com> wrote: > While everyone *hopes* there are never going to be any further incompatible > changes to HTML in the future, there *is* a possibility that in some > unfortunate situation, it will be necessary to introduce incompatible > changes. In that case, it will be necessary to introduce a new version > indicator, to allow (alas) processors to determine which of the incompatible > interpretations was meant. If the new version is going to be incompatibile anyway, why not add the version indicator at that time? > While this will be unfortunate, it would be > doubly unfortunate to have to introduce a new “place” for a version > indicator that was previously non-conforming, which would cause even worse > uproar, because documents that *didn’t* want the new incompatible behavior > would have no place to say explicitly that which version of the incompatible > behavior they wanted. We wouldn't need to invent a new "place" for this information, we could just resurrect this proposal to use the old place. The documents that don't want the new behavior can just use the HTML5 doctype of "<!DOCTYPE html>". If we were certain that this eventuality would come to pass, we might want to optimize for it by providing a more elegant alternative, but the current indications are that this not a likely course of events. > By *allowing* a verison indicator in conforming > content today, we can avert more serious damage. Having a location for a > version indicator, even if it isn’t explicitly used, allows it to be used at > some point in the future. This is the core of your argument, but if the future version we're planing for is incompatible anyway, why does it matter if it re-introduces versioned doctypes? You're not asking for anything to change for user agent implementations, so it's not like user agents will act differently in your alternative future. You explicitly tell authors not to use the extended syntax: "A PublicIdentifier SHOULD NOT be used," so the extant documents on the world-wide web at this future time when we need an incompatible version will likely be the same. All that seems to change is the conformance status of documents produced *after* the new incompatible spec is issued. Moreover, it's only the conformance status of those document w.r.t. the *old* specification. That seems like pedantry in the extreme. > In the history of computer languages, there are no > languages that have not evolved, been extended, or otherwise "versioned" as > long as the language has been in use. Really? Where are the version indicators for C++? The C++ languages has certainly evolve since its inception, but it hasn't needed an explicit version indicator. It seems entirely likely that HTML will continue to evolve without a version indicator because the mechanism we've been using for versioning has been more or less ignored because authors screw it up too much. > This applies to network protocols, > character encoding standards, programming languages, and certainly to every > known technology found on the web. That's quite a bold claim and certainly untrue. > There are no known cases where a language > hasn't gone through some at least minor incompatible change. Right, but that doesn't mean we need a version indicator. HTML has gone though a number of minor incompatible changes and the world has managed not to end in spite of everyone ignoring the version indicator. In summary, we don't need to add versioning now to future-proof the spec because the effects of this change are felt only after we discover an incompatible version is required. Attempting to prepare for that eventuality as described in you change proposal doesn't actually do anything substantive to help. Adam
Received on Sunday, 3 January 2010 18:39:15 UTC