Re: Obsolete vs rescinded vs superseded recommendations

Hi Florian,

TL;DR: What you are calling Superseded seems to be a strict subset of what  
the process document is trying to do by introducing "obsolete" IMHO. And  
IMHO, I don't think there is enough importance in recognising different  
subsets to justify distinguishing them in the process. But there are some  
gems in here too…

Did you read Ian Jacobs' recent review comments? He provided an omnibus  
review so you need to wade through a lot of other stuff, but he made what  
I think are some valuable comments on the proposal for Obsolete and  
Rescinded Recs that I think are relevant to your points here.

On Tue, 09 Aug 2016 06:15:15 +0200, Florian Rivoal <florian@rivoal.net>  
wrote:

> The rescinding process looks appropriate when "W3C discovers burdensome  
> patent claims", but since rescinded documents are no longer covered by  
> the patent policy, it is less clear that it is a good fit for  
> recommendations that would be fine on their own, but are replaced by and  
> are in conflict with later specifications.
>
> The process to obsolete recommendations seems somewhat more relevant for  
> such documents, but that's not what the process document calls for.
>
> Let's take for instance documents like CSS2.0  
> (https://www.w3.org/TR/2008/REC-CSS2-20080411/), or CSS1  
> (https://www.w3.org/TR/CSS1/), setting aside for a minute that fact that  
> they predate the current process or the current patent policy. These  
> have been replaced by newer documents which occasionally conflict with  
> them, and no errata is being maintained (CSS2.1 does have errata when  
> newer specs conflict, and not all of it has been replaced, so it's not  
> relevant here).
>
> From a patent point of view, if the newer REC is a strict superset of  
> the old one, the old one no longer being covered by the patent policy  
> wouldn't be a problem, but if they have, as sometimes happens,  
> conflicting normative requirements, there could be cases of patents  
> having claims that cover one but not the other.

Yes, but this isn't a new problem. It can be annoying, but it doesn't  
seem, in practice, to have led to a serious amount of trouble. While I  
don't think we should be blind to the issue, I think it's not a very big  
one in practice.

> Is the current practice of including prominent (albeit ad-hoc) warning  
> notes in such specifications sufficient? Should they be rescinded?

IMHO we could reasonably *rescind* CSS 2.0 - but before we tried to do the  
same to HTML 3.2 and 4 we should clarify the situation for HTML in email,  
which is close to HTML 5.x in webmail clients and those that incorporate a  
modern HTML engine, but not so much in Outlook's MS Word-based engine.

But I'm not sure the Director would agree.

> Should they be Obsoleted? Should we create another "Superseded" status?  
> Does the answer depend on whether the document in question predates the  
> patent policy?

I don't think the additional marginal value of a "Superseded" justifies  
its cost, since I think it covers one of the cases where documents should  
be obsoleted.

I do think that some of the ideas you outline below would be improvements  
on our current proposal for obsoletion.

> In short, my idea of a Superseded REC would be:
>
>  - the patent policy continues to apply (if it ever did)

This is the case for Obsoleted docs.

>  - new implementations are discouraged, and SHOULD refer to the newer  
> document instead

This is generally a goal, as I understand it, but see the caveat below

>  - new TR documents MUST NOT normatively refer to it (informative  
> references for historical purposes are OK)

This is the case

>  - The superseded REC MUST have (a) link(s) to the document(s) that  
> supersede it

This isn't the case. One reason is that while in some cases a document is  
made obsolete by another document - e.g. HTML 3.2 and CSS 2.0, in others  
the entire technology has been replaced by something else as is the case  
IMHO for e.g. CC/PP and PICS.

There is a further case where there isn't really a replacement, but the  
world seems to have gone in a different direction. For example P3P aims to  
solve a problem that seems to still exist, and that doesn't seem to have a  
different solution, but the world is not implementing P3P, and doesn't  
seem *likely* to do so.

For the second, and especially the third case, marking the document  
Obsolete is recognising reality. And if the reality changes e.g. because  
people suddenly start implementing P3P en masse, then we should, with  
Keynes, keep up :)

>  - The superseded REC SHOULD state whether the document that replaces it  
> is merely an extension, or whether they have conflicting normative  
> requirements (this is only a should, because making it a must might get  
> in the way of marking as superseded RECs that should be, when it is not  
> known whether there are conflicts, and nobody is stepping up to do the  
> work needed to find out).

Agreed. I think it is fair to require that an Obsolete Rec's updated  
version explain *why* it was made Obsolete, which is a generalisation of  
this that neither conflicts with nor supersedes (ha ha) it.

> One key difference with Obsolete RECs is that the the only case I can  
> think of for a superseded REC to become a normal REC again is if the  
> document that superseded it is itself rescinded due to patent claims.

I think that case is a generally applicable rationale for restoring an  
obsolete document.

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Wednesday, 10 August 2016 03:34:14 UTC