Align terminology with W3C API

[tidoust]

After further discussions, idea is to align terminology used here with that used in the W3C API.

In particular, goal is to use:

• series to link levels/versions of the same spec together.
• shortname to mean both the "name with version" and the "name without version". In other words, the series property should typically be an object with a shortname property.
• seriesVersion, with a x, x.y or x.y.z string value, to identify the level/version of a spec in a series
• currentSpecification to reference the current specification from a series object

[tidoust]

For a couple properties, we probably actually want to depart from W3C terminology, typically to convey the notions of TR and ED URLs, that only really make sense in a W3C context.

One idea would be to reuse software terminology and talk about:

• nightly: The latest draft. Matches the Editor's Draft for W3C specs, the living document for WHATWG specs, the published spec for Khronos Group specs.
• release: A published snapshot if it exists. Matches the TR spec for W3C specs published there, the Editor's Draft for W3C specs not yet published to TR, the living document for WHATWG specs, the published spec for Khronos Group specs.

Both properties would be always set (and would thus be set to the same value for living specs and specs that have not been released yet).

[andreubotella]

There has to be some subtlety to what counts as a release, since the WHATWG specs have review drafts, which although they are published snapshots, are also considered as obsolete from the get-go. Maybe "a published snapshot considered to be more stable than the nighly version, if it exists".

Also, there needs to be some way to distinguish specs which have no release version by design, like the WHATWG specs, and specs which haven't been published to TR yet but are expected to in due time.

[tidoust]

There has to be some subtlety to what counts as a release, since the WHATWG specs have review drafts, which although they are published snapshots, are also considered as obsolete from the get-go. Maybe "a published snapshot considered to be more stable than the nighly version, if it exists".

Right, I wasn't planning to make release point at the latest WHATWG review draft of a spec since, as you note, they are considered obsolete as soon as they're published, and so don't seem to be very useful objects to look at in practice.

I don't mind using terms other than release and nightly by the way. I just haven't managed to find better terms :)

Also, there needs to be some way to distinguish specs which have no release version by design, like the WHATWG specs, and specs which haven't been published to TR yet but are expected to in due time.

Do we need to know? And if we do, what do we need to know?
For instance, should WICG and other community group specs be counted as specs that are expected to be published to TR in due time?

[tidoust]

Last commit introduced the terms release and nightly, with a small twist compared to what I proposed earlier: release is only set for publications that have a clear release process, in practice only for W3C specs developed by working groups.

If it seems useful to have more details about the actual lifecycle process that a spec is following, I believe the right approach would be to expose the group and organization that develops the spec. I'll create a separate issue to track this.