Add audio/opus to audio core media types

[mattgarrish]

Includes a link to issue 645, which we should keep open if we're not fully committed to inclusion yet.

A couple of issues I had with this PR, though:

• I've added audio/opus as the mime type, but I spotted the note about using audio/ogg for Opera. Since this is just the package document declaration, I assume we don't need to account for both.
• From what I've read, Opus is also supported in WebM and MP4 containers, but I assume we're only supporting Ogg since that's all that was discussed.

If I'm assuming wrong on either of these points, please chime in.

---

Preview | Diff

[dauwhe]

Perhaps the note could provide a bit more context?

Core media types must be widely supported on all platforms used for EPUB Reading Systems. OPUS/OGG has good support in Android, MacOS, Windows, and Linux. Apple, starting with iOS 11, supports the OPUS codec, but only in a CAF container. The working group will monitor support for OPUS in iOS, and may remove OPUS as a core media type if we feel the level of support is inadequate.

[iherman]

Perhaps the note could provide a bit more context?

Core media types must be widely supported on all platforms used for EPUB Reading Systems. OPUS/OGG has good support in Android, MacOS, Windows, and Linux. Apple, starting with iOS 11, supports the OPUS codec, but only in a CAF container. The working group will monitor support for OPUS in iOS, and may remove OPUS as a core media type if we feel the level of support is inadequate.

I agree with such a separate note; I believe we agreed on that on the call. If we do so, we can remove the reference to #645 from the table (which gets very distorted by this; we can refer to it from the note).

[iherman]

I believe this is the first clearly technical change on the spec (ie, not an editorial change). Maybe it is worth to set a changes' section in the document(s) right away and list this one there.

[shiestyle]

I just shared this topic to Japanese industry and I appreciate that this will be merged if nobody has negative feedback before the next call.

[mattgarrish]

Perhaps the note could provide a bit more context?

That's fine, but I think we should drop the first sentence. In part because if clarification about what core media types are is needed, we should raise that separately, but also because it's more nuanced (i.e., widely supported on reading systems that support the rendering of the resources, which is a mouthful for an issue).

I agree with such a separate note

I'll disagree with this approach as it leads to issues being forgotten about. It's an open issue, so let's use the facilities that exist for them exactly so they're obvious to readers. If we move it to a note after the table, is anyone going to read that far on to find the additional context?

Maybe it is worth to set a changes' section in the document(s) right away and list this one there.

Yes, I realized I forgot this late last night but didn't think anyone would notice before morning. :)

But it raised the question for me of whether we need a separate changes document anymore now that we only have one content specification and one reading system? The changes document was a place to collect all the major changes from across all the separate specifications. I'd much prefer to have a changes log in each document and have one less document to publish at the end.

[mattgarrish]

Slightly branching off from the actual issue, but I've incorporated change logs for the three primary specs. We should have listed the spec re-org after formally adopting it, and for the accessibility document I've noted the ISO revisions have been incorporated.

[iherman]

I agree with such a separate note

I'll disagree with this approach as it leads to issues being forgotten about. It's an open issue, so let's use the facilities that exist for them exactly so they're obvious to readers. If we move it to a note after the table, is anyone going to read that far on to find the additional context?

You are right that the automatic Issue handling via respec is a good thing. We can use that (and be careful to document that issue properly!)

I think if it is put right after the table it is clearly visible, and it is editorially better in my view. That distortion of the table itself is ugly, and the issue is right after the table...

Maybe it is worth to set a changes' section in the document(s) right away and list this one there.

Yes, I realized I forgot this late last night but didn't think anyone would notice before morning. :)

But it raised the question for me of whether we need a separate changes document anymore now that we only have one content specification and one reading system? The changes document was a place to collect all the major changes from across all the separate specifications. I'd much prefer to have a changes log in each document and have one less document to publish at the end.

I actually did not realize we have a separate changes document until you just said that:-) I absolutely agree that using the 'standard' approach of a change lot in each document is way better. Actually, I wonder if the pubrules checker would not complain if we do not have that section... So yes, i would think the old changes document could be just dumped as historical and start fresh with a changes section with 3.2 being the base line.

[mattgarrish]

I think if it is put right after the table it is clearly visible, and it is editorially better in my view.

Fair enough!