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?

[marcoscaceres]

Yes, I believe that is correct.

[tobie]

That wouldn't be immediate, though. W3C would need to republish the spec for this change to be effective.

[plehegar]

@palemieux . it is indeed correct. Since 3rd is a CR, you could make the update in the editor's draft and our system would pick that up at the next publication.

[palemieux]

Ok. Thanks, so it sounds like this issue can be closed? Would it make sense to document this thread in respec... for future generations?

[tobie]

Yeah, the underlying problem is that W3C doesn't have a real defined concept of what a version or an edition is. I'm not too sure where that issue should be filed, @plehegar?

[plehegar]

@tobie, https://github.com/w3c/guide/ would be the place. Version management is documented in https://www.w3.org/2005/05/tr-versions at the moment but could be moved into the Guide repo.

[skynavga]

From my perspective, the problem is that IMSC doesn't employ the correct URL. The intent of the generic URL is to be fluid, and be updated as new editions are created. By using that URL in IMSC, you get a non-fixed resource to dereference (and must live with it). On the other hand, if IMSC wants to refer to a specific edition, then it should do so, and thus have a fixed resource to dereference.

[nigelmegitt]

For information, w3c/ttml1#353 is in a holding pattern pending any clear agreement on how W3 is going to handle this. It's clear already from #463 (comment) that using a subtitle in h2 is an option, but that further work would be needed, perhaps in backend tooling, to populate the title shown in specref with the unqualified (no subtitle) one for generic spec URLs and the qualified (concatenated with subtitle) one for specific spec URLs.

[tobie]

Deleted a bunch of comments that were referencing a comment @skynavga had changed in the meantime and that were thus adding confusion.

[tobie]

@nigelmegitt to clarify my position here, handling versions and editions is an automated way in Specref is a lot of work that I'm not expecting anyone to feel like doing (and then supporting), or be willing to pay for in the near future. I wouldn't expect a resolution to this issue under 18 months. Not to mention that this potentially relies on prior work at the W3C level (which might add another year to the equation).

[nigelmegitt]

Thanks @tobie that's useful information. I had the impression from @plehegar that possibly specref would not be changed at all and the only change would be in backend W3 systems.

[tobie]

further work would be needed, perhaps in backend tooling, to populate the title shown in specref with the unqualified (no subtitle) one for generic spec URLs and the qualified (concatenated with subtitle) one for specific spec URLs.

I'm unable to tell whether adding support for this in Specref—granted it was actually added on the W3C side and exposed in W3C's rdf file (which Specref still relies on)—is a 5 minute job, or requires a complete re-architecture of the project. There is a lot of technical debt in Specref.