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.

Sign up for GitHub

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

Make encrypted-media an alias of encrypted-media-2 #810

Merged
merged 2 commits into from
Aug 20, 2024
Merged

Make encrypted-media an alias of encrypted-media-2 #810

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
10c49f2
Make encrypted-media an alias of encrypted-media-2
tidoust Aug 19, 2024
b3cec77
Create dated alias entries directly in refs/w3c.json
tidoust Aug 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion overwrites/w3c.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,5 +15,6 @@
{ "id": "PNG", "action": "createAlias", "aliasOf": "png-3"},
{ "id": "media-source", "action": "renameTo", "newId": "media-source-1" },
{ "id": "media-source-1", "action": "replaceProp", "prop": "href", "value": "https://www.w3.org/TR/media-source-1/" },
{ "id": "media-source", "action": "createAlias", "aliasOf": "media-source-2" }
{ "id": "media-source", "action": "createAlias", "aliasOf": "media-source-2" },
{ "id": "encrypted-media", "action": "createAlias", "aliasOf": "encrypted-media-2" }
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't you also fix this one in the file?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently, I can't... If I update w3c.json directly, the encrypted-media entry gets back to being an alias of encrypted-media-1 next time the w3c.js script is run.

Looking into it, I suspect that's due to tr.rdf, which contains:

<rdf:Description rdf:about="https://www.w3.org/TR/encrypted-media-1/">
  <formerShortname>encrypted-media</formerShortname>
  <sameWorkAs rdf:resource="https://www.w3.org/TR/encrypted-media/"/>
</rdf:Description>

I suppose the intrepretation is that since encrypted-media-1 used to be known as encrypted-media, then encrypted-media should be an alias of encrypted-media-1. That interpretation is sound in the absence of better info. Unfortunately tr.rdf does not know much about specification series either...

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't want to block you on this, but can't you fix this upstream?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upstream in tr.rdf? As far as I know, the file is maintained as is because several projects (including Specref) need it, but without any attempt to add new features at this point. I don't know where the code that produces tr.rdf file lies in practice. It may not be public. @deniak would know!

Now, there is nothing to fix per se in tr.rdf. The file just does not know that encrypted-media-1 and encrypted-media-2 are part of the same series of specs whose shortname is encrypted-media, and that the second level is the current one. It just knows that the encrypted-media-1 spec used to be known as encrypted-media, which is indeed correct. The W3C API would be a better source for Specref down the road, and would allow to add proper support for specification series. Same thing, that's not really a fix though, more a whole new feature ;)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iirc, fixing those somewhere was possible (as it also maps what happens to redirects, e.g. https://www.w3.org/TR/encrypted-media/ -> https://www.w3.org/TR/encrypted-media-2/), but no problem if that's an issue for you to fix.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as it also maps what happens to redirects

Does it? Looking at the w3c.js script in Specref, the only way to end up with an alias seems to be with this formerShortname mechanism. The tr.rdf file has a notion of superseding that gets used in Specref to flag entries as obsoleted by another entry, but that's not what I'd like here: I'd like people to be able to continue referencing the latest version of the spec with encrypted-media. Also, ReSpec at least does not seem to warn authors when an obsoleted spec gets referenced.

Specref has a notion of levels - code is in leveled.js - but that's a hardcoded list (with only WebIDL so far), and it seems to be more about merging entries.

What makes this case a pain is that encrypted-media used to be the shortname of the spec that is now encrypted-media-1. It now is the series shortname of a family of specs whose current level is encrypted-media-2. Things would have been easier if encrypted-media-1 had existed from day 1: there would have been no encrypted-media entry (similar to the way there is no css-fonts entry but only css-fonts-3, css-fonts-4, css-fonts-5), which would have avoided any confusion. The starting point for this PR is that authors of specs referencing encrypted-media now get confused because the reference still goes to level 1.

Instead of trying to make things somewhat work in Specref, perhaps we should not do anything and rather ask people to use encrypted-media-2, at least until we figure out a way to support series shortnames in Specref?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for the record, tr.rdf is generated from data we have in the database. Now, as @tidoust mentioned, it lacks some features such as the series, which creates some problems like the one you are discussing. The goal is to discontinue it in favor of the API but if tr.rdf generates some infinite loop because of these former shortnames, I can try to untangle the data.

Copy link
Owner

@tobie tobie Aug 20, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, there's a bunch of elements in tr.rdf doing things like:

<rdf:Description rdf:about="https://www.w3.org/TR/resource-timing/">
    <formerShortname>resource-timing-2</formerShortname>
    <sameWorkAs rdf:resource="https://www.w3.org/TR/resource-timing-2/"/>
</rdf:Description>

That's what I had in mind. But don't feel like this is what you have to do at all. I'm totally fine merging this as is.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I recorded the possibility to support specification series in #811. Will merge as is :)

]
141 changes: 141 additions & 0 deletions refs/w3c.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55531,6 +55531,147 @@
},
"repository": "https://github.com/w3c/encrypted-media"
},
"encrypted-media-20130510": {
"aliasOf": "encrypted-media-1-20130510"
},
"encrypted-media-20131022": {
"aliasOf": "encrypted-media-1-20131022"
},
"encrypted-media-20140218": {
"aliasOf": "encrypted-media-1-20140218"
},
"encrypted-media-20140828": {
"aliasOf": "encrypted-media-1-20140828"
},
"encrypted-media-20150331": {
"aliasOf": "encrypted-media-1-20150331"
},
"encrypted-media-20150928": {
"aliasOf": "encrypted-media-1-20150928"
},
"encrypted-media-20151010": {
"aliasOf": "encrypted-media-1-20151010"
},
"encrypted-media-20151019": {
"aliasOf": "encrypted-media-1-20151019"
},
"encrypted-media-20151027": {
"aliasOf": "encrypted-media-1-20151027"
},
"encrypted-media-20151116": {
"aliasOf": "encrypted-media-1-20151116"
},
"encrypted-media-20151120": {
"aliasOf": "encrypted-media-1-20151120"
},
"encrypted-media-20151130": {
"aliasOf": "encrypted-media-1-20151130"
},
"encrypted-media-20160122": {
"aliasOf": "encrypted-media-1-20160122"
},
"encrypted-media-20160202": {
"aliasOf": "encrypted-media-1-20160202"
},
"encrypted-media-20160204": {
"aliasOf": "encrypted-media-1-20160204"
},
"encrypted-media-20160208": {
"aliasOf": "encrypted-media-1-20160208"
},
"encrypted-media-20160209": {
"aliasOf": "encrypted-media-1-20160209"
},
"encrypted-media-20160216": {
"aliasOf": "encrypted-media-1-20160216"
},
"encrypted-media-20160218": {
"aliasOf": "encrypted-media-1-20160218"
},
"encrypted-media-20160225": {
"aliasOf": "encrypted-media-1-20160225"
},
"encrypted-media-20160227": {
"aliasOf": "encrypted-media-1-20160227"
},
"encrypted-media-20160325": {
"aliasOf": "encrypted-media-1-20160325"
},
"encrypted-media-20160328": {
"aliasOf": "encrypted-media-1-20160328"
},
"encrypted-media-20160329": {
"aliasOf": "encrypted-media-1-20160329"
},
"encrypted-media-20160330": {
"aliasOf": "encrypted-media-1-20160330"
},
"encrypted-media-20160404": {
"aliasOf": "encrypted-media-1-20160404"
},
"encrypted-media-20160412": {
"aliasOf": "encrypted-media-1-20160412"
},
"encrypted-media-20160414": {
"aliasOf": "encrypted-media-1-20160414"
},
"encrypted-media-20160416": {
"aliasOf": "encrypted-media-1-20160416"
},
"encrypted-media-20160421": {
"aliasOf": "encrypted-media-1-20160421"
},
"encrypted-media-20160426": {
"aliasOf": "encrypted-media-1-20160426"
},
"encrypted-media-20160428": {
"aliasOf": "encrypted-media-1-20160428"
},
"encrypted-media-20160429": {
"aliasOf": "encrypted-media-1-20160429"
},
"encrypted-media-20160514": {
"aliasOf": "encrypted-media-1-20160514"
},
"encrypted-media-20160517": {
"aliasOf": "encrypted-media-1-20160517"
},
"encrypted-media-20160518": {
"aliasOf": "encrypted-media-1-20160518"
},
"encrypted-media-20160520": {
"aliasOf": "encrypted-media-1-20160520"
},
"encrypted-media-20160527": {
"aliasOf": "encrypted-media-1-20160527"
},
"encrypted-media-20160531": {
"aliasOf": "encrypted-media-1-20160531"
},
"encrypted-media-20160601": {
"aliasOf": "encrypted-media-1-20160601"
},
"encrypted-media-20160602": {
"aliasOf": "encrypted-media-1-20160602"
},
"encrypted-media-20160603": {
"aliasOf": "encrypted-media-1-20160603"
},
"encrypted-media-20160609": {
"aliasOf": "encrypted-media-1-20160609"
},
"encrypted-media-20160610": {
"aliasOf": "encrypted-media-1-20160610"
},
"encrypted-media-20160705": {
"aliasOf": "encrypted-media-1-20160705"
},
"encrypted-media-20170316": {
"aliasOf": "encrypted-media-1-20170316"
},
"encrypted-media-20170918": {
"aliasOf": "encrypted-media-1-20170918"
},
"eo-qb": {
"authors": [
"Dmitry Brizhinev",
Expand Down
Loading