process should clarify how Superseded state interacts with other maintenance processes (e.g., new versions, edited/amended recommendations)

[dbaron]

The creation of the superseded state has caused some confusion in the CSS working group, in particular related to the discussion in w3c/csswg-drafts#2589.

My memory of the creation of superseded was that it resulted from objections to calling something obsolete that was actually superseded by a later version.

However, this has created the impression to some in the CSS WG that this creates an obligation to mark things as superseded. The process should be clearer which sorts of revisions cause one specification to automatically be superseded by another, and which sorts require marking something as superseded. For example, does it matter if something was an edited/amended Recommendation (versus maintenance that adds new features), or whether it had the same shortname, or whether it was produced by the same or a successor working group, or whether it has the same name (but maybe a different version)?

[dwsinger]

Oh dear. This state was an opportunity to clean house. There is neither obligation nor automation, rather, opportunity to clean /TR of historical references, which remain available for reference, but we want to steer new readers and implementers to something later.

…

Sent from my iPhone

On May 2, 2018, at 5:00 PM, L. David Baron ***@***.***> wrote: The creation of the superseded state has caused some confusion in the CSS working group, in particular related to the discussion in w3c/csswg-drafts#2589. My memory of the creation of superseded was that it resulted from objections to calling something obsolete that was actually superseded by a later version. However, this has created the impression to some in the CSS WG that this creates an obligation to mark things as superseded. The process should be clearer which sorts of revisions cause one specification to automatically be superseded by another, and which sorts require marking something as superseded. For example, does it matter if something was an edited/amended Recommendation (versus maintenance that adds new features), or whether it had the same shortname, or whether it was produced by the same or a successor working group, or whether it has the same name (but maybe a different version)? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dbaron]

BTW, I think one reasonable place to draw the line might be:

• if you have the ability to (reasonably) make the non-dated URL for a spec refer to the newer document, do that instead
• otherwise, the Superseded state may be appropriate

[dwsinger]

I don't think I understand what line you are trying to draw. We wanted to be able to do two things (a) clean up the /TR page so it only showed 'current' versions, not historical and (b) if someone lands on an old spec., somehow, they get alerted that it's been superseded by something newer, and that's what they should implement, consider current, etc. Often, the new spec and the old have the same name but different version numbers, but sometimes there is a change of name (to protect the innocent) and what superceded what is not at all obvious to the non-cognoscenti of the web...

[dbaron]

I'm trying to draw a line for when a WG should use the Superseding process.

In other words, what my line would say that if CSS 2.0 has a "Latest version" link that goes to CSS 2.1 (which I believe is in the process of being fixed), then there's no need to publish a Superseded Recommendation for CSS 2.0 pointing to CSS 2.1. But at some point in the future, CSS 2.1 will be superseded by other CSS modules but there isn't a single target that the WG can ask to have its "Latest version" link pointed to, then there is a need to publish a Superseded Recommendation describing what has replaced it.

[chaals]

Noting that there is no requirement to supersede a Recommendation, I would approach it differently.

As far as I can tell, CSS 2.0 is superseded - by 2.1 - and it makes sense to republish it to make that clear.

While bits of CSS 2.1 are superseded by individual modules, the spec as a whole is not superseded.

IMHO it would be helpful to publish a new Recommendation which contains the "still live" bits, points to the relevant modules, and mark the current 2.1 as superseded by that.

If 2.1 were entirely superseded by new modules, and the WG doesn't want a "core" Recommendation spec, it would also be reasonable to publish 2.1 as superseded, and note that it is superseded by some collection of specs.

In either case, this is up to the WG to decide, since they are still active.

[vfournier17]

Egads! This seems far too complicated! I agree with publishing a new version of a spec (2.1) and calling the prior version (2.0) superseded.

However, I wouldn't want to be the poor implementer who has to try to patch together "some collection of specs" that supersedes the prior spec (2.0). I think the logical expectation is that each version (2.1) supersedes the version before it (2.0)

[chaals]

Lucky for you, you are not that implementor.

Reality turns out to be messy. Some implementors have actively requested that specs be broken into various pieces, others that apparently unrelated things be bundled together. Where (and if) the lines are drawn ends up being somewhat ad hoc... and is generally guided by input from implementors.

I think we need to recognise that, allow for the diversity of reality that Working Groups face, and trust them to make reasonable judgements.

[vfournier17]

How would you determine essential patent commitments and exclusion opportunities with a spec that's a hodgepodge of documents, or a one-off customized specification? I understand facing reality, but patent owners probably don't want to inadvertently grant a RF patent license because a customized or bundled spec was created, without an exclusion opportunity (e.g., combination claim patents).

[nigelmegitt]

If a spec is updated and bits of the old one remain unchanged but other bits are changed, and the overall scope of the spec remains the same, then the new spec should be a "whole new truth" so that the previous spec can be superseded in its entirety. In other words, we should normally copy across the unsuperseded parts rather than refer back to a "partly superseded" previous version. There are certainly examples where this approach has been taken.

Helping folk understand what has changed and not changed is important - that's why change summaries and logs and diffs are useful.

There's a separate conversation to be had here about best practices when modularising specs, but that's a whole other topic.

[dwsinger]

@vfournier17 happily we are only talking about slapping the label "superceded", and some text explaining where better to look, here. The actual development of the hodge-podge, mish-mash, or whatever, is part of the normal process, along with commitments, comments, and so on.

One of the reasons for the superceded status is where Bananas 1.5 was not superceded by the obvious Bananas 2.0, but by Veg and Fruit 1.0; or vice versa, where Veg, Fruit and Cheese 10.7 was superceded by Fruits 1.0, Veg 1.0, and Dairy Products 3.0 (which in turn superceded Milk 2.0). Labels and text are needed in this case to avoid the innocent getting stuck in apparent dead-ends.

[vfournier17]

@dwsinger Got it, thanks.

[fantasai]

I would like to point out that the shortname of CSS2.0 and that of CSS2.1 are identical, i.e. 'CSS2'. (Historically, we had /TR/REC-CSS2 being 2.0 and /TR/CSS21/ being 2.1, but they were merged under the same shortname some years ago.)

@chaals This means that a republication of CSS2.0 to mark it superseded would have to be published as an update to CSS2.1... which makes no sense.

[chaals]

Hmm. https://www.w3.org/TR/REC-CSS2/ takes me to the CSS 2.0 Recommendation from 1998. https://www.w3.org/TR/CSS2/ takes me to the 2.1 Recommendation as edited in 2016. Republishing the 1998 document as superseded by the CSS2.1 recommendation doesn't seem like a problem to me - what am I missing?

---

Note by @frivoal : While true at the time of writing, "https://www.w3.org/TR/REC-CSS2/ takes me to the CSS 2.0 Recommendation from 1998" is no longer true as of 2018/10/02, as the redirect mentioned in #183 (comment) has been put in place

[dbaron]

The CSS WG has asked the team to redirect https://www.w3.org/TR/REC-CSS2/ like it also redirected https://www.w3.org/TR/CSS2/ and https://www.w3.org/TR/CSS21/ to the latest CSS 2.1. That was just an omission.

Given that it was an omission -- is the right thing to do to ask the team to fix the "latest version" link that was missed along with all the other latest version links -- or is it to go through the superseding process? That was part of my original question.