Re: Deprecated vs. obsolete

Hi, Krzysztof-

Krzysztof Maczyński wrote (on 9/19/09 9:56 AM):
>
> The definition of deprecated in DOM 3 Events ED is peculiarly different
> from typical spec usage, within W3C and elsewhere.

I don't see a conflict between the DOM3 Events definition of 
"deprecated" and other definitions in W3C specs [1] or Wikipedia [2]. 
The definition in DOM3 Events is more specific, true... this is to 
account for the rather peculiar history of this specification.

It began as an Rec-track document, but stalled when browsers stopped 
implementing new specifications, and was shelved as a W3C Note in 2003, 
so it was never a Recommendation, and should not have been considered 
stable.  Between that point and the point where we picked it up again 
for revision, however, implementers did start implementing bits and pieces.

Now we have a situation where we again have active participation by 
browser vendors, and there are features in DOM3 Events, and older 
features defined in DOM2 Events, that implementation experience has 
shown us are problematic, and which many implementers don't want to 
support, or that were simply never implemented.

We are also defining some features that were never standardized, but 
which are commonly implemented and which may be useful.  For those that 
are common, but not as useful, we define them for completeness, but 
deprecate them.


>I believe deprecated
> should still mean MUST for implementors but SHOULD NOT for authors. The
> appropriate term encompassing SHOULD NOT for authors and SHOULD NOT or
> MAY for implementors is obsolete.

AIUI, "obsolete" is a term introduced in HTML5, and I don't believe it's 
needed or significant from a specification perspective.


>Furthermore, even in that case SHOULD
> NOT for implementors seems too strong for me, maybe it should be MAY and
> strengthened to SHOULD NOT only when there are better replacements already
> available, not just in progress?

There are many reasons for deprecation... some are listed in the 
Wikipedia article [3].  It is a broad term, and I think it's wholly 
applicable here.


> There are features I'm soon going to suggest be deprecated but which for
> legacy compatibility would need to remain MUST for implementors.
>
> Requiring a complete and superior substitute before lifting MUST from implementors
> is a good thing. Otherwise an attempt against which I was one of those
> to protest in the following thread could happen here as well:
> http://lists.w3.org/Archives/Public/www-style/2009Mar/0097.html.

That would defeat the purpose of this specification, which is to define 
a set of features that are going to be implemented in all major 
browsers, while warning authors which features are likely to work only 
in legacy browsers.  For example, mutation events are a mess, and 
authors need to avoid their use, so that we can start moving toward a 
replacement; authors should not count on them being universally 
implemented, either.

However, if others disagree, I'll reconsider my position.

[1] http://www.w3.org/2003/glossary/keyword/All/?keywords=deprecated
[2] http://en.wikipedia.org/wiki/Deprecation
[3] http://en.wikipedia.org/wiki/Deprecation#Reasons_for_deprecation

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 19 September 2009 19:31:51 UTC