Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permanent latest level identifier for drafts #2548

Open
annevk opened this issue Apr 12, 2018 · 6 comments
Open

Permanent latest level identifier for drafts #2548

annevk opened this issue Apr 12, 2018 · 6 comments
Labels

Comments

@annevk
Copy link
Member

annevk commented Apr 12, 2018

E.g., I'd like to use [SELECTORS] in DOM and have it always reference the latest version, rather than having to use [SELECTORS4], then 5, etc.

@tabatkins
Copy link
Member

Related to this, the W3C has revamped its URL structure so that you can use level-less URLs to link directly to the "stable" and "latest" version of a spec.

@fantasai
Copy link
Collaborator

fantasai commented May 29, 2018

I think this is a specref issue? CSSWG always has unleveled shortnames available for linking.

@annevk
Copy link
Member Author

annevk commented May 30, 2018

Did you discuss with @tabatkins since they directed me here? Re-opening for now.

@annevk annevk reopened this May 30, 2018
@tabatkins
Copy link
Member

Yeah, I directed @annevk here first, since it probably impinges on how we want to represent things inside the W3C.

@AmeliaBR
Copy link
Contributor

In general, I don't think we can add the spec shortname to SpecRef as a "living standard" reference, because in many cases the shortname already exists in SpecRef as an alias to a level 1 version of that spec.

Instead, we'd need to adopt a [shortname-suffix] convention, with the suffix indicating "the latest version".

But that begs the question: what do you want (@annevk), when you want "the latest version"?

Do you want the latest "TR" version? Or the latest Editor's Draft? Neither version is guaranteed to live up to the rigour expected of a true living standard.

The problem with the Editor's Drafts are that they are updated informally. Editor's make changes, then ask the group to review them after they are live. And they are often incomplete & marked explicitly as not ready for implementation.

One problem with the TR versions is that they are often out of date. I know working group chairs & staff contacts are trying to do better about this. But at times, there have been widely agreed upon and implemented changes that have not been formally published for years. But even when they are regularly updated, the latest TR version may still be an incomplete working draft that isn't ready for implementation.

I still think it's a good idea to have a [shortname-ED] SpecRef convention for referencing the latest complete editor's draft, meaning whatever you'd get at https://drafts.csswg.org/shortname/. And something like [shortname-latest] or [shortname-TR] for whatever you'd get at https://www.w3.org/TR/shortname/

But with either shorthand URL, you aren't necessarily going to get a version of the spec that is ready to implement.

It would be nice if W3C publications supported a https://www.w3.org/CR/shortname/ URL that redirected to the latest version that is marked CR or better (and similar for PR or better, or only the latest Rec). But in order for that to be really useful, we'd need publishing processes that encouraged more frequent and granular updates, for whenever an individual feature is ready to implement (aka "cleared for shipping" by the working group), or inter-operably implemented.

PS. This really needs a "Process" or "Meta" label, but I don't see anything applicable in the labels list.

@annevk
Copy link
Member Author

annevk commented Jun 1, 2018

I'm pretty sure WHATWG wants to refer to editor's drafts. Latest "stable" too often doesn't include whatever the standards depend on. And that's also what we want folks to be reviewing.

(Ideally you'd write Living Standard too, or apply a similar rigor to the editor's drafts, but I can't have it all I suppose. It does seem that if you really want to goof of as editor you could do that in a branch and not put it in a document folks are also trying to implement from.)

@annevk annevk added the meta label Jun 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants