Make encrypted-media an alias of encrypted-media-2 #810
Conversation
The `encrypted-media` entry was an alias of `encrypted-media-1`, but the series shortname should now redirect to `encrypted-media-2`. Unfortunately, this means adding a bunch of aliases to preserve previous dated entries. That's slightly ugly (although easy to prepare with a good text editor that supports multi-line edits) but I don't think there's a better way until Specref understands series shortnames.
|
That sounds like overkill. Can't you just add them directly in the file? |
Sure! Done. How does that look? |
| @@ -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" } | |||
There was a problem hiding this comment.
Can't you also fix this one in the file?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
Don't want to block you on this, but can't you fix this upstream?
There was a problem hiding this comment.
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 ;)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
OK, I recorded the possibility to support specification series in #811. Will merge as is :)
In all honesty: bad, but maybe a little less bad? |
The
encrypted-mediaentry was an alias ofencrypted-media-1, but the series shortname should now redirect toencrypted-media-2.Unfortunately, this means adding a bunch of aliases to preserve previous dated entries. That's slightly ugly (although easy to prepare with a good text editor that supports multi-line edits) but I don't think there's a better way until Specref understands series shortnames. Or is there?