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

Handling editions of W3C recommendations #463

Open
palemieux opened this issue Apr 26, 2018 · 27 comments
Open

Handling editions of W3C recommendations #463

palemieux opened this issue Apr 26, 2018 · 27 comments

Comments

@palemieux
Copy link
Collaborator

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
Copy link
Owner

tobie commented Apr 26, 2018

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
Copy link
Collaborator Author

@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
Copy link
Owner

tobie commented Apr 26, 2018

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

@palemieux
Copy link
Collaborator Author

palemieux commented Apr 26, 2018

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
Copy link
Owner

tobie commented Apr 26, 2018

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
Copy link
Collaborator Author

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

@tobie
Copy link
Owner

tobie commented Apr 26, 2018

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
Copy link
Collaborator Author

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
Copy link
Owner

tobie commented Apr 26, 2018

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

@palemieux
Copy link
Collaborator Author

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

@plehegar
Copy link
Contributor

plehegar commented May 1, 2018

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
Copy link
Collaborator

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
Copy link
Contributor

plehegar commented May 2, 2018

(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
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator

Yes, I believe that is correct.

@tobie
Copy link
Owner

tobie commented May 7, 2018

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

@plehegar
Copy link
Contributor

plehegar commented May 7, 2018

@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
Copy link
Collaborator Author

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
Copy link
Owner

tobie commented May 7, 2018

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
Copy link
Contributor

plehegar commented May 7, 2018

@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
Copy link

skynavga commented May 7, 2018

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
Copy link
Collaborator

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.

Repository owner deleted a comment from plehegar May 15, 2018
Repository owner deleted a comment from skynavga May 15, 2018
Repository owner deleted a comment from plehegar May 15, 2018
@tobie
Copy link
Owner

tobie commented May 15, 2018

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

@tobie
Copy link
Owner

tobie commented May 15, 2018

@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
Copy link
Collaborator

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
Copy link
Owner

tobie commented May 15, 2018

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.

tidoust added a commit to tidoust/specref that referenced this issue Dec 5, 2023
When MSE was published as a REC, it did not have levels. That changed. The
unversioned URL now targets Level 2, which is not the Rec.

This update renames the shortname of the Rec from `media-source` to
`media-source-1`, updates the URL for that level to
`https://www.w3.org/TR/media-source-1/`, and creates a `media-source` alias
to turn the `media-source` entry into a "current version" URL.

Specs that currently use `[[MEDIA-SOURCE]]` to reference MSE will now target
the level 2 WD and not the level 1 Rec, but then they were targeting the Rec
with the URL of WD, so the reference was clumsy in any case. All of these
specs are in the Media WG in any case (except HTML, but HTML references the
Editor's Draft, so nothing changes there...).

Note that there is no generic mechanism in Specref to handle such series. Some
discussion in tobie#463.
tidoust added a commit that referenced this issue Dec 5, 2023
When MSE was published as a REC, it did not have levels. That changed. The
unversioned URL now targets Level 2, which is not the Rec.

This update renames the shortname of the Rec from `media-source` to
`media-source-1`, updates the URL for that level to
`https://www.w3.org/TR/media-source-1/`, and creates a `media-source` alias
to turn the `media-source` entry into a "current version" URL.

Specs that currently use `[[MEDIA-SOURCE]]` to reference MSE will now target
the level 2 WD and not the level 1 Rec, but then they were targeting the Rec
with the URL of WD, so the reference was clumsy in any case. All of these
specs are in the Media WG in any case (except HTML, but HTML references the
Editor's Draft, so nothing changes there...).

Note that there is no generic mechanism in Specref to handle such series. Some
discussion in #463.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants