Editorial: let ReSpec handle id assignment #337
Conversation
There was a problem hiding this comment.
This update changes the effective ID of exported definitions. For instance, it will change init-segment to dfn-initialization-segment.
The problem is that byte stream format specs reference these exported terms, e.g., see links in the Initialization Segments section in MPEG-2 TS Byte Stream Format.
These specs have the same issue as MSE: they still use custom JavaScript to manage cross-references. They would certainly benefit from being updated as well, but since we don't really have plans to update the published byte stream formats specs any time soon, I would suggest to keep the explicit ID for terms that are exported.
No problem for non-exported terms.
|
MPEG-2 TS Byte Stream Format is a tiny note though. Couldn't we (by which I mean I) update it and just put that on auto publish too? These are just spec heath changes so shouldn't impact anything... we could even keep the same date for the Note if we wanted to and no one would notice the difference. |
We sure can and I'm happy to help. Note that we need to update the 5 byte stream format specifications, which all expect the |
This refreshes the spec to leverage ReSpec cross-referencing capabilities. See discussion in w3c/media-source#337 (comment) ReSpec currently (rightfully) issues warnings because some of the MSE terms are defined informatively in MSE, whereas they should rather be defined in a normative section, as noted in: w3c/media-source#325 (comment)
|
@marcoscaceres I prepared a refresh of the ISO BMFF Byte Stream Format spec to see what that would involve, see w3c/mse-byte-stream-format-isobmff#12. If that looks fine, happy to do the same for the other specs (and then we can setup auto publish). |
|
That would be amazing! Thanks for handling the other doc! |
|
@tidoust, please merge this when you are ready in coordination with the other PR when ready. Thanks again! |
This refreshes the spec to leverage ReSpec cross-referencing capabilities. See discussion in: w3c/media-source#337 (comment) Section 3 contained a reference to "ISO/IEC 13818-1:2012 Amd. 2". As far as I can tell, there have been no revision of 13818-1 dated 2012, so that reference is incorrect. The closest might be "ISO/IEC 13818-1:2013/Amd 2:2014" but this version has been replaced by newer versions in any case. This update simply uses `[[MPEG2TS]]`.
See discussion in w3c/media-source#337 (comment) The references to ID3v1 and ID3v2 remain in the local biblio for now because the id3.org server, which hosts the specifications, returns a 500 Internal Server Error (and has been returning that error in the past few months). Not quite sure what to do with that. Also, Specref has ID3 v2.4.0, but the spec probably means it when it references v2.3.0 as that is the "main" one in practice.
See discussion in w3c/media-source#337 (comment) Fragment references to WebM Container Guidelines spec need to be done through `data-cite` because the spec is not in the cross-references database (and does not follow usual conventions for definitions).
This refreshes the spec to leverage ReSpec cross-referencing capabilities. See discussion in w3c/media-source#337 (comment) ReSpec currently (rightfully) issues warnings because some of the MSE terms are defined informatively in MSE, whereas they should rather be defined in a normative section, as noted in: w3c/media-source#325 (comment)
This refreshes the spec to leverage ReSpec cross-referencing capabilities. See discussion in: w3c/media-source#337 (comment) Section 3 contained a reference to "ISO/IEC 13818-1:2012 Amd. 2". As far as I can tell, there have been no revision of 13818-1 dated 2012, so that reference is incorrect. The closest might be "ISO/IEC 13818-1:2013/Amd 2:2014" but this version has been replaced by newer versions in any case. This update simply uses `[[MPEG2TS]]`.
See discussion in w3c/media-source#337 (comment) Fragment references to WebM Container Guidelines spec need to be done through `data-cite` because the spec is not in the cross-references database (and does not follow usual conventions for definitions).
See discussion in w3c/media-source#337 (comment) The references to ID3v1 and ID3v2 remain in the local biblio for now because the id3.org server, which hosts the specifications, returns a 500 Internal Server Error (and has been returning that error in the past few months). Not quite sure what to do with that. Also, Specref has ID3 v2.4.0, but the spec probably means it when it references v2.3.0 as that is the "main" one in practice.
Byte stream format specs and registry have now been updated not to rely on the custom |
SHA: be0d251 Reason: push, by tidoust Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Preview | Diff