Handling editions of W3C recommendations

[palemieux]

As it stands, it looks like like entries like TTML1 refers to the most recent version of TTML1, which is fine since references to specific versions, e.g. ttml1-20041101 are also available.

It looks like there is however an issue with the TTML1 entry as it is current generated:

Glenn Adams; Pierre-Anthony Lemieux. Timed Text Markup Language 1 (TTML1) (Third Edition). 24 April 2018. W3C Candidate Recommendation. URL: https://www.w3.org/TR/ttml1/ ED: https://w3c.github.io/ttml1/index.html

The URL points to the Latest Version link https://www.w3.org/TR/ttml1/ and not the This Version link https://www.w3.org/TR/2018/CR-ttml1-20180424/.

This is an issue across editions. As an example, IMSC 1.0.1 refers to TTML1. When IMSC 1.0.1 was published, only TTML1 2ED has been published, and so the reference reads:

Timed Text Markup Language 1 (TTML1) (Second Edition). Glenn Adams. W3C. 24 September 2013. W3C Recommendation. URL: https://www.w3.org/TR/ttml1/

The URL https://www.w3.org/TR/ttml1/ however now points to TTML1 3ED. This is pretty confusing to readers, and may yield issues if IMSC 1.0.1 had in fact relied specifically on TTML1 2ED.

Would it make sense for the URL of entries such as TTML1 to point to the This Version link?

[tobie]

Would it make sense for the URL of entries such as TTML1 to point to the This Version link?

Well, we'd need something consistent. So this couldn't be specific to certain entries, or to even to specs which have multiple editions (as there's little consistency as to how those are represented). At the same time, the behavior you describe is desired for a number of use cases, so we cannot replace it altogether.

There's a number of things that could be done here. But each one is substantial and would possibly require coordinating with the different tools that rely on Specref.

Unless someone is willing to invest the resources needed to build and support this, I think your best bet is to go for dated numbers, or possibly just created aliases for the versions you care about.

[palemieux]

@tobie How are the references to W3C recommendations generated?

At the same time, the behavior you describe is desired for a number of use cases, so we cannot replace it altogether.

Which use cases? It seems undesirable to have the name of the specification in the reference not matched the specification to which the URL points to.

[tobie]

The use case is specs that don't change name across version and/or edition.

[palemieux]

Ok. So if there was a means of extracting the title without the edition number, then that name could be used, and so, for example, the TTML1 reference would be generated as:

Glenn Adams; Pierre-Anthony Lemieux. Timed Text Markup Language 1 (TTML1). 24 April 2018. W3C Candidate Recommendation. URL: https://www.w3.org/TR/ttml1/ ED: https://w3c.github.io/ttml1/index.html

Did I get this right?

[tobie]

Edition numbers and version numbers are really complicated to handle because everyone does them differently and has a different understanding of what they mean. I have no idea how to fix that without some serious re-engineering of how Specref considers, stores, and handles data.

From Specref's perspective a title is a title. Unless the spec changes shortname as is changes version/edition, we'll have these URL issues.

[palemieux]

Understood. I plan to follow-up with W3 staff for their opinion.

[tobie]

We had a number of conversations with @plehegar and @deniak on the topic. And it ties in to some of the work they've been doing.

[palemieux]

Thanks for the pointers. Totally thinking out loud, it might be good if the W3 specifications had metadata that contains a canonical title, independently of edition number and pub date -- just like the spec status is not embedded in the title.

[tobie]

I don't disagree. Some editors and WGs do, however.

[palemieux]

That makes us two at this point, which is bigger than 1 :)

[plehegar]

Note that respec handles subtitles., eg https://w3c.github.io/pointerevents/

Now, compare the data from
https://www.specref.org/?q=pointerevents2

and the actual WD at https://www.w3.org/TR/pointerevents2/
(the subtitle got dropped in specref)

This is because we don't expose through our API those subtitles. So, if you actually want to drop edition and version numbers, the solution is to put them as a subtitle (in html, this means use an h2 instead of h1).

[marcoscaceres]

Watching with interest... does the W3C API derive the "title" from <title> or from the head's <h2>. If it's getting it from <title>, then we can maybe concatenate the spec's title and subtitle, into title (subtitle). But, PubRules would need to allow <tile> and <h2> to differ.

[plehegar]

(I think you mean head's h1, not head's h2. I misspoke earlier when I said "instead of h1". You always need the h1 but you can use an additional h2 for the subtitle)

Not sure about the API but the title of a spec is extracted from the h1 in pubrules using
https://github.com/w3c/specberus/blob/master/lib/rules/metadata/title.js

If I understand correctly, the actual "official" metadata that gets into our API is extracted by a separate mysterious metadata script/job. @deniak would know more here.

In any case, as you pointed out, pubrules enforces title === h1 in
https://github.com/w3c/specberus/blob/master/lib/rules/headers/h1-title.js

I actually like the way it is at the moment, ie you have the choice to put the version number in the title of the spec or leave as a subtitle in the h2. In other words, if you want <title> to contain the version number, make it part of the h1.

[marcoscaceres]

I actually like the way it is at the moment, ie you have the choice to put the version number in the title of the spec or leave as a subtitle in the h2. In other words, if you want <title> to contain the version number, make it part of the h1.

Agree.

[palemieux]

So... in the case of TTML1, you are suggesting that (Third Edition) could be carried in an h2 so that it is not picked up by spec-ref?