Re: Updated DOCTYPE versioning change proposal (ISSUE-4)

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