Do we need a superseded status for older specs?

[dwsinger]

We have some older recommendations that are still published as they are important references (e.g. HTML 3, 4). The technology in them has been wholly subsumed by later versions, and we no longer want to maintain them actively. Do we need a process to mark them as superseded?

[chaals]

I would prefer to mark them as obsolete. They remain Recommendations, and they are available if people want them, but there is a clearer indicator that this is a historical document not "what the Web is doing now"…

I'm not sure what we gain by separating "obsolete" and "superseded" as different kinds of document - other than complexity in Process.

[dwsinger]

I would be fine with including it in obsoleted, but I think then that the explanation page needs an update from:

An obsolete specification is one that the W3C community has decided should no longer be used. For example, it may no longer represent best practices, or it may not have received wide adoption and seems unlikely to do so in the future.

to: An obsolete specification is one that the W3C community has decided should no longer be used. For example, it may have been superseded by a more recent specification, may no longer represent best practices, or it may not have received wide adoption and seems unlikely to do so in the future.

[LJWatson]

Agree with @Chaals that keeping it simple is the better approach, and the words from @DWSinger LGTM.

[dwsinger]

OK, we seem to be converging. We surely don't need an AC ballot to declare something superseded, though, do we? That's just noise.

[chaals]

If we are superseding an older spec with a newer version, it seems fair to roll the questions into the one ballot.

Which is probably better than just assuming that "someone" will take care of deciding what to supersede... especially in the presumably anomalous case where the AC thinks for some reason that version x, version x-1 and version x+1 should all be considered current...

[dwsinger]

Adding the question to an existing ballot is fine by me, and is a good optimization. We might need a sentence in the process, sigh, that such can done.

[chaals]

The relevant Process section 7.1.1 says

... The Call for Review describes the proposal, ...

I think that's broad enough to allow a compound question to be put, or two questions to be put. But I don't mind if we do add some words, if someone has some good ones.

[tantek]

@dwsinger, your proposals seem like a reasonable path forward here (without introducing more bureaucracy). Quick question: did you (or anyone) look at how IETF does superseding to see if there is some existing art/convention/process that we can re-use instead of re-invent?

[dwsinger]

On Jun 15, 2017, at 18:18 , Tantek Çelik notifications@github.com wrote:

@dwsinger, your proposals seem like a reasonable path forward here (without introducing more bureaucracy). Quick question: did you (or anyone) look at how IETF does superseding to see if there is some existing art/convention/process that we can re-use instead of re-invent?

They put ‘obsoleted by RFC XXXX’ in the header of superseded specs.

I think the moral equivalent is our existing “Latest published version”

David Singer Manager, Software Standards, Apple Inc.

[paulbrucecotton]

I think the moral equivalent is our existing “Latest published version”

I would have thought the W3C equivalent is something like what appears in the XQuery 1.0 spec:

"Note: This paragraph is informative. This document is currently not maintained. This document remains available on the W3C's Technical Report web page for reference and use by interested parties. Readers are advised that no further maintenance (including correction of reported errors) is planned for this document. Readers interested in the most recent version of the XQuery specification are encouraged to refer to http://www.w3.org/TR/xquery-3/."

/paulc

[dwsinger]

Concretely, edit the process here:

W3C may obsolete a Recommendation, for example if the W3C Community decides that the Recommendation no longer represents best practices, or is not adopted and is not apparently likely to be adopted. An Obsolete Recommendation may be restored to normal Recommendation, for example because despite marking it Obsolete the specification is later more broadly adopted.

to say

W3C may obsolete a Recommendation, for example if the W3C Community decides that the Recommendation no longer represents best practices, or is not adopted and is not apparently likely to be adopted, or is superseded by a more recent Recommendation. An Obsolete Recommendation may be restored to normal Recommendation, for example because despite marking it Obsolete the specification is later more broadly adopted.

and before

If there was any dissent i

add

When a Recommendation is obsoleted because it is being superseded, the advisory committee ballot on whether to advance to Recommendation may also include the request to obsolete prior versions.

[chaals]

Concrete proposal from the editor - not superseding as a reason for obsoleting, but not specifically point out that the director can ask two questions at once. Pull Request coming shortly.

[LJWatson]

Related issue #39 may be superseded if we update the definition of obsolete as suggested above.

[LJWatson]

One possibility might be to use "superseded" instead of "obsolete" as the term, whilst leaving the definition as it is (or at least how it's been revised above)?

Initial comments on the proposal to make previous versions of HTML and XHTML obsolete suggest that people are getting caught on the term, rather than its definition.

[dwsinger]

I don't think we can use 'superceded' for specs we think are no longer useful, but for which there is nothing newer. Frankly, an older version of a spec. IS obsolete; you may have good reason to refer to HTML4 Transitional, but it's NOT the current status and being told you're using an obsolete spec. should not be a surprise. I'm having a hard time finding a better term than obsolete for something which has either been superceded or we feel is no longer relevant, but am open to ideas...

[LJWatson]

Agree @dwsinger. I'm just wondering whether we're going to fight an uphill battle every time we want to make a "not quite the latest" version of a spec obsolete - as seems likely to be the case with HTML5.0.

[dwsinger]

Open to grabbing a thesaurus once I get home and seeing if there is a more neutral word. But a completely neutral word is not what we want; we do want to guide people towards the latest spec.

[LJWatson]

Doing some quick research...

Definition of "supersede":

• Take the place of;
• Displace in favour of another;
• Set something aside.

Synonyms for "supersede":

• Annul;
• Overrule;
• Repudiate;
• Set aside;
• Supplant.

Definition of "obsolete":

• No longer in use, gone into disuse, disused or neglected (often in preference for something newer that has replaced it);

Synonyms for "obsolete":

• Antiquated;
• Archaic;
• Out of date;
• Out moded;
• Anachronistic;
• Ancient;
• Antidiluvian;
• Antique.

To some extent these words seem interchangeable to me. This seems to advocate the revised definition of an obsolete spec suggested above.

That said, there may be an argument for W3C using both (an obsolete spec being one that is so ancient/out of date it has fallen into disuse, and a superseded spec being one that is still in use but that has been replaced by a newer version). The obvious problem with this, is that it's highly likely that every version of every spec is still in use somewhere by some thing or other, meaning it would be next to impossible to ever make a spec obsolete.

[caribouW3]

Well, from my non-native speaker perspective, obsolete means old stuff out of date, whereas superseded means replaced by, and calls for a ref to the replacement (while obsolete does not).

[dwsinger]

Yes, something that has been superseded is (almost by definition) obsolete; but we can have obsolete specs which have not been superseded but effectively abandoned. So 'obsolete' as the umbrella actually feels right. Most of the other terms imply some passage of time ("before the flood") or value judgment ("out moded").

[chaals]

So I sort of changed my mind. Clearly many people understand "obsolete" to mean something worse than superseded. The majority of the web, let alone the world is a non-native speaker of english.

I think there is scope in the current process for saying that something has the status of "Ob-Rec" because it has been superseded - after all, a huge amount of this is about perception, and perception depends on what we actually say.

So in part we could deal with this by implementation - but if we don't manage that, I am now open to the idea of complicating the process more to simplify what people understand. As @dwsinger notes, there are things that are just plain obsolete by any understanding. I suspect there are many more things that are superseded - because things that matter get a new version more often.

[dwsinger]

Responding to Chaals: I am not sure what you are suggesting. At the moment we have the category 'obsolete' which includes two categories: obsolete because we no longer think this is implemented or should, or represents current practice; and obsolete because superseded.

[michaelchampion]

@dwsinger -- if we lived in a world driven by logic I would agree: superseded is a subset of obsolete so no change is needed. But in a world where feelings triggered by word associations do matter, and "obsolete" SOUNDS worse than "superseded", making these separate labels seems appropriate.

[dwsinger]

Separating the words is easy, that's the explainer page.

[tantek]

@michaelchampion I do think it's beyond feelings and has some basis in logic / important meaning.

tl;dr: Obsolete = dead. Superseded = living, but not this version/permalink. Totally different.

E.g. contrast:

Obsolete has all the negative implications of failure, abandonment, stay away from this thing or anything like it, and don't bother trying anything like this again unless you have a really good reason why it will turn out differently.

Additionally: was always a bad idea (doomed, academic, impractical, overly complex, solution looking for a problem etc.) and just had to let the market prove it by ignoring it, or preferring other approaches.

Obviously not all of those are true for everything that is obsolete. Yet I'd say a handful typically apply to each example.

Superseded has fairly consistent positive implications of past, present, and future:

• was supported (implemented! critical mass!) enough to warrant iteration, upgrading, evolution
• newer version has proven itself (as successful) at least as well as previous version to declare it a replacement
• likely indication of a healthy community / ecosystem that has incentive to continue evolving it in the future

Also having just read the dictionary/thesaurus analysis above, these terms in the context of standards (IETF, others) have far more subtle/precise meanings attached to them than a general language dictionary/thesaurus is going to provide. I don't expect any such reasoning from dictionary/thesaurus lookups to be useful to resolve this.

[LJWatson]

The more I think about this, the more I think the simplest solution would be to rename "obsolete" as "superseded", and revise the definition in a reversal of the text proposed by @dwsinger. Perhaps:

"A superseded specification is one that the W3C community has decided should no longer be used. For example, it may have been replaced by a more recent specification, may no longer represent best practices, or it may be considered obsolete because it no longer has wide adoption and seems unlikely to do so in the future.">

We could add "superseded" as a third state, but I'm not sure of the benefit. It turns out that identifying an obsolete specification isn't a simple matter. As David Wood notes elsewhere, HTML3.2 is still widely used in email systems, and HTML4.1 and XHTML1.1 are both still used in enterprise platforms.

What we really need to do is clearly communicate which version of a specification is considered the authoritative version, and I think "superseded" accomplishes this.

[dwsinger]

Leonie, I think the clear meaning of the word "superseded" is that something (newer) has taken its place. That's not true for P3P and Pics -- we have nothing newer to refer to, the whole design direction was abandoned.

I think that the process section needs only minor change, if anything https://www.w3.org/2017/Process-20170301/#rec-rescind, probably only to make it clear that superseded is included -- see this PR https://github.com/w3c/w3process/pull/50/files.

I don't think it's problematic for the process to use the term 'obsolete', because it happens to be true.

The explainer page https://www.w3.org/2016/11/obsoleting-rescinding/ is the one that needs editing. The heading should say "Obsolete and/or Superseded" and the text something more like:

Obsolete or Superseded specifications are ones that the W3C community no longer recommend for new adoption. For example, there may be newer specifications, they may no longer represent best practices, or they may not have received wide adoption and seem unlikely to do so in the future. These recommendations can nonetheless be adopted and they remain active under the W3C Patent Policy.

If the W3C community discovers at a later date that the reasons for a specification being declared obsolete or superseded are no longer valid, the process may be reversed.

More information on the process for making a specification obsolete/superseded can be found in section 6.9 of the W3C Process.

If you think that a specification has been marked as such in error, please contact the W3C.

[dwsinger]

Process needs to edit this definition to say Obsolete or Superceded: Obsolete Recommendation An Obsolete Recommendation is a specification that W3C does not believe has sufficient market relevance to continue recommending that the community implement it, but does not consider that there are fundamental problems that require the Recommendation be Rescinded. It is possible for an Obsolete Recommendation to receive sufficient market uptake that W3C decides to restore it to Recommendation status. An Obsolete Recommendation has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR licenses granted under the Patent Policy.

Then matching edits to 6.9 to include superceding in the same process.

[jeffjaffe]

Obsolete documents and Superceded documents should follow the identical process.

In the case that the obsolete document is superceded by a different document it should be designated as superceded. If it is obsoleted for any other reason, it should be designated as obsolete.

[dwsinger]

Change the definition of Obsolete Recommendation:

Obsolete or Superceded Recommendation An Obsolete Recommendation is a specification that W3C does not believe has sufficient market relevance to continue recommending that the community implement it, but does not consider that there are fundamental problems that require the Recommendation be Rescinded. It is possible for an Obsolete Recommendation to receive sufficient market uptake that W3C decides to restore it to Recommendation status. A Superceded Recommendation is a Recommendation with a newer version which the W3C recommends for new adotption. An Obsolete or Superceded Recommendation has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR licenses granted under the Patent Policy.

Change the title of 6.9 to: Rescinding a W3C Recommendation or declaring it Obsolete or Superceded

Change the first two paragraphs to read: It is possible that W3C decides that implementing a particular Recommendation is no longer recommended. There are three designations for such specifications, chosen depending on how strongly W3C wishes to advise against using the specification.

W3C may obsolete a Recommendation, for example if the W3C Community decides that the Recommendation no longer represents best practices, or is not adopted and is not apparently likely to be adopted. An Obsolete Recommendation may be restored to normal Recommendation, for example because despite marking it Obsolete the specification is later more broadly adopted.

W3C may declare a Recommendation Superceded if a newer version exists which the W3C recommends for new adoption. The process for declaring a Recommendation Superceded is the same as for declaring it Obsolete, below; only the name and explanation change.

[LJWatson]

With reference to #57, a slight rewrite of the first chunk of the proposed text from @dwsinger:

"An Obsolete Recommendation is a specification that the W3C believes no longer has enough market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded. It is possible for an Obsolete specification to regain enough market relevance that the W3C decides to restore it to Recommendation status. A Superseded Recommendation is a specification that has been replaced by a newer version that the W3C recommends for new adoption. An Obsolete or Superseded specification has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy.">

[dwsinger]

LGTM. Thanks for merging

[chaals]

@dwsinger is your comment above a resoution to be implemented, or a proposal?

[dwsinger]

my comment was agreeing to Leonie's merge of the other issue and thanking her for it, so the current proposal is my full text amended by Leonie's re-write of that section

[vfournier17]

I like Léonie's version as well.

[ylafon]

Sorry for commenting on a closed issue, but IETF is using "obsolete" and "historical" (see https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html ). So maybe using in W3C's case "historical" to match IETF for old major versions of specifications (like HTML3 or HTML4) would make more sense then just "obsolete".

[chaals]

@ylafon please look at what was merged in the editor's draft.

I would be happy with the name 'historical' instead of 'superseded', but I am not that concerned either way.

I think that what does need to be done for this version is work out if we have integrated whatever we choose cleanly

• is there one state, or are there two? (I don't care in practice)
• is there any need to be able to move from one to the other (I don't think so)
• are there mentions elsewhere we should have picked up? (Quite possibly...)

[dwsinger]

is there one or two states? formally/procedurally, there is one state, but it has two permitted labels to clarify what the specific conditions that led to this state are (obsolete or superseded)

I suppose we might re-start work on an obsolete spec. and supersede it, but I think we could leave it, or change the marking, and it doesn't matter. there's no reason to declare a superseded cpec. also obsolete, we would obsolete TOT.

editors catch other mentions...

[dwsinger]

so, the IETF uses:

• A document is obsolete when there is a newer version that replaces it. RFC 821 is obsoleted by RFC 2821, which is, in turn, obsoleted by RFC 5321. The technology that RFC 821 describes — SMTP — is still current technology, but the documentation of it in RFC 821 is obsolete.
• A document is labelled Historic when what it describes is no longer considered current: no longer recommended for use.

so IETF obsolete = W3C superseded IETF historic = W3C obsolete

ugh. maybe we need to note this somewhere. or should we align?

[tantek]

A couple of things, in reverse order:

1. IETF uses "obsoletes" and "updates" as verbs. E.g. in RFC 6350 (vCard4)

http://www.ietf.org/rfc/rfc6350.txt

"Obsoletes: 2425, 2426, 4770" and "Updates: 2739"

Not sure if that helps your obsolete, vs. superseded vs. historic terminology problem @dwsinger but I wanted to provide another real world example for reasoning.

Note that 2426 (vCard3) is still very much the dominant interoperably supported "level" of vCard, and if you were going to implement .vcf support today, it would be more market relevant for you to support vCard3 than vCard4 (which is still being adopted incrementally as implementations need its features).

2. Thank you @dwsinger and @LJWatson for the patched process text - in general it looks really good.

One phrase (and aspect) that particularly concerns me: "no longer has enough market relevance" implies that an obsolete spec once did have enough market relevance (due to the temporal phrase "no longer"), which, frankly, for many W3C RECs, was NEVER true (W3C pretended as much in the bad old pre-CR days of often purely aspirational standards which had zero implementations/market relevance, only political relevance, by default).

I would prefer something more neutral that does not imply the prior state either way, e.g. "lacks sufficient market relevance".

Similar problem in the following sentence with the use of "regain". That following sentence is also too passive.

Complete paragraph in context with suggested complete replacement:

Replace this:

"An Obsolete Recommendation is a specification that the W3C believes no longer has enough market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded. It is possible for an Obsolete specification to regain enough market relevance that the W3C decides to restore it to Recommendation status."

With this:

"An Obsolete Recommendation is a specification that the W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded. If an Obsolete specification gains sufficient market relevance, the W3C may decide to restore it to Recommendation status."

[dwsinger]

fine by me. I think the older wording was a euphemism to suggest we didn't make a mistake, but the world moved in a way we didn't expect. but it's a fig leaf

[tantek]

Explicit political face-saving (defensively "suggest we didn't make a mistake") is a poor thing to encode into process wording IMO. Hence the more neutral wording which withholds judgment.

[vfournier17]

Should this: “. . . which does not have fundamental problems that would require it to be Rescinded.”

be replaced with this: “. . . which does not have fundamental TECHNICAL problems that would require it to be Rescinded.”?

It could have other fundamental problems, such as lack of currency, or cosmetic or political issues - but would any such problems be enough to rescind a spec?

Best regards,

Virginia Fournier Senior Standards Counsel  Apple Inc. ☏ 669-227-9595 ✉︎ vmf@apple.com mailto:vmf@apple.com

On Sep 11, 2017, at 4:20 PM, Tantek Çelik notifications@github.com wrote:

Political face-saving ("suggest we didn't make a mistake") is a poor thing to encode into process wording IMO.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/w3process/issues/36#issuecomment-328685895, or mute the thread https://github.com/notifications/unsubscribe-auth/AZj-G7ehNAVzOo56RzR6xIQmOmQW2Cdqks5shcBOgaJpZM4NISHC.

[chaals]

Patent issues could be non-technical reasons to rescind a W3C Recommendation. I think that is the canonical use case, but there may be others. I suggest we do not restrict them. Indeed, W3C has never even made a spec obsolete, and attempts to rescind things led to the creation of the softer "obsolete" category.

[dwsinger]

I think the process is clear that rescinsion is for specs for which we perceive we have a licensing problem that we don't think we can resolve. "there is no reasonable prospect of it being restored for example due to burdensome patent claims that affect implementers and cannot be resolved; see the W3C Patent Policy [PUB33] and in particular section 5 (bullet 10) and section 7.5." (The punctuation of that could be improved, I note). I'd rather not fiddle with this; rescinsion was not on our list of things to work on. (Though the editor is welcome to fix the punctuation).