Re: Obsolescence notices on old specifications, again

* Ms2ger wrote:
>The recent message to www-dom about DOM2HTML [1] made me realize that we 
>still haven't added warnings to obsolete DOM specifications to hopefully 
>avoid that people use them as a reference.

If you want to say more than that the specifications are no longer being
maintained and which newer specifications might contain more recent de-
finitions for the features covered you will have to create a process for
that first (it would require Advisory Committee review for instance, as
otherwise you are likely to create unnecessary drama).

>I propose that we add a pointer to the contemporary specification to the 
>following specifications:
>
>* DOM 2 Core (DOM4)
>* DOM 2 Views (HTML)
>* DOM 2 Events (D3E)
>* DOM 2 Style (CSSOM)
>* DOM 2 Traversal and Range (DOM4)
>* DOM 2 HTML (HTML)
>* DOM 3 Core (DOM4)

As far as I am aware, "CSSOM" is an unmaintained and incomplete set of
ideas, and what of it reflects actually implemented behavior and what
may change tomorrow is anyone's best guess so that is clearly not a
suitable replacement.

"DOM4" fails to define many widely implemented features and makes many
backwards-incompatible changes, I don't see how someone who wants to im-
plement the DOM in Java would use the draft rather than the Recommen-
dations as a starting point, especially not now as it's rather unclear
how much consensus behind all the various proposed changes is outside a
rather narrow group of people around the draft's editors. It's a stretch
to call it a specification at all, it's more like a reference implemen-
tation in an ad-hoc assembly language that's not very useful for people
who are not "Web browser DOM implementation maintainers".

If you want to know if setAttributeNS changes the namespace prefix, you
go to the DOM Level 3 Core specification which will tell you "If an
attribute with the same local name and namespace URI is already present
on the element, its prefix is changed ..." as the second sentence; you
don't go to "DOM4" and debug the code there to combine the facts that it
sets `prefix` to a certain value in step #4, does not change it in the
steps 5-9, and then does not use the value in step ten, into the
conclusion that unless you missed some subtlety in the code, or the many
definitions it relies on, that it does not change it. And a reviewer is
unlikely to even notice the proposal would change the behavior.

The proposal pretends that .createElement creates elements in the XHTML
namespace. That is not what all current browsers do, it's not what non-
browser implementations currently do, and probably not what they should
do or are likely to do in the future. So how does that help people who
do not already know about "DOM4" and would not use DOM Level 2 Core as a
reference anyway?

For DOM Level 2 HTML the proposed alternative is indeed better at least
in some regards like coverage, so a pointer would make some sense.

>and a recommendation against implementing the following specifications:
>
>* DOM 3 Load and Save
>* DOM 3 Validation

You will have to use the Rescinding process for that, and this would re-
quire a legal analysis of the impact of rescinding the Recommendations
(Validation does not seem to indicate under which Patent Policy it has
been produced, and Load and Save was produced under the transitional
rules; under the 2004 Patent Policy rescinding a Recommendation has im-
plications on licensing requirements, and it is not clear to me whether
people who wish to implement either specification in a year from now to
replace some legacy product with backwards-compatibility would be worse
off if the documents were rescinded).

I also note that you have made no argument why these should be rescinded
beyond perhaps that web browser developers might not want to implement
it currently if they haven't already done so. That is not something to
capture in the status of these documents.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 24 January 2012 00:59:01 UTC