Relationships to SMIL and to EPUB 3 Media Overlay

[iherman]

§2 touches upon this, but it only says:

SyncMedia is an evolution of EPUB3 Media Overlays and, like Media Overlays, is built on [SMIL3]. Compared to Media Overlays, SyncMedia incorporates additional SMIL concepts, and also includes custom extensions.

At some point in time, this section should be much more explicit. There are some questions to be answered:

1. Is Sync Media a superset of EPUB's Media Overlays (i.e., is any conformant Media Overlay file a valid Sync Media file)? E.g., is it o.k. to use epub:type in a SyncMedia? If this is the goal, we have to be careful of being compatible with Media Overlays wherever that is applicable.
2. Is Sync Media a superset of SMIL 3? Obviously not, but there must be clear relationships. E.g., that Sync Media uses some aspects of SMIL 3, i.e., it is a (very) restricted version of SMIL, borrowing, whenever possible, SMIL 3 features.
3. Is Sync Media a subset of SMIL 3 (i.e., is any conformant Sync Media file a valid SMIL 3 files regarding all elements and attributes it uses?

From a practical point of view, and taking my EPUB 3 work's hat on, I would love to see Sync Media as a clear extension to Media Overlays, i.e., a 'yes' to (1) above. That would mean possibly replacing the EPUB 3 Overlays eventually in a later version of EPUB 3. (Recognizing that Sync Media might be useful outside if EPUB, too, of course.)

I would also think that (3) is a worthy goal, although has less practical value because EPUB seems to be the only environment where SMIL still lives.

Whatever the goal is, some general motivation, use cases, etc., for the extensions and features would be necessary to, e.g., justify the inclusion into the publication world. A use case section, or a reference to use cases, would therefore be important.

[marisademeglio]

You can find use cases in our documents list here: https://w3c.github.io/sync-media-pub/

Outlining the differences between SyncMedia and Media Overlays will be a good document to add to that list.

Off the top of my head, I think that:

• SyncMedia does not support epub:type, which wanted to be called role but we were told not to use role at that time
• SyncMedia does not support epub:textref, but rather supports multiple parallel text references
• SyncMedia uses param to control styling; MO uses metadata in the package doc and offers far less flexibility
• SyncMedia does not restrict multiple parallel timed media, thus providing a path forward for iBooks authors who used the "background music" feature (not an official MO feature)
• SyncMedia encourages references to embedded media via the actual media object, e.g. <video src="doc.html#vidElement"/>; MO would instead use <text src="doc.html#vidElement"/> (and then you don't get clipping), which now that we have a richer media object vocabulary, doesn't make sense.

I think this last point especially opens the door to SyncMedia working with an existing HTML layout to make it come to life. Demos soon...

But, back to the main point, the relationship between MO and SyncMedia and SMIL -

• Is a valid SMIL3 document plus sync: extensions still considered a valid SMIL3 document?
• As it stands, SyncMedia is not a superset of MO but there is a path for MO to be transformed into SyncMedia without losing any information.

[iherman]

Forgive me if I sound overly critical (it is not my intention!) but I just try to foresee the obstacles ahead of us if we want to carry this work further...

I looked at the Use case list (thanks for the pointer) but that is not a "real" use case document that would be considered as such by an external reader. They would look for real-life stories of, say, EPUB publication to be produced for a particular community that cannot be done by today's technologies.

Looking at your summary:

• Is a valid SMIL3 document plus sync: extensions still considered a valid SMIL3 document?

Probably not, but that is not really the important question; I believe the question is whether a valid SMIL 3 document will also be valid as a SyncMedia document or not (whereby I of course mean a SMIL 3 document that uses only the features listed in the SyncMedia spec).

That being said, as I said in my comment: I can live perfectly well if there is a clear (and documented) incompatibility with SMIL 3; the relationship to MO is way more important. I have not seen any significant uptake of SMIL 3 outside the EPUB world, so…

• As it stands, SyncMedia is not a superset of MO but there is a path for MO to be transformed into SyncMedia without losing any information.

We have lost a lot of energy when working on the EPUB 3 WG charter around the issue of whether current and valid EPUB 3.2 publications would remain valid under EPUB 3.3. There is a clear business demand to do so. If we want SyncMedia to replace Media Overlays in some EPUB 3.x then I am not sure that this approach would fly easily. I would still consider this as an open issue...

In any case: my main point was that, somewhere in the SyncMedia document, the differences v.a.v. MO and SMIL must be made explicit. It can be in the Appendix, in a separate section, I do not really care, but the reader should be able to find it easily.

[larscwallin]

Hi @iherman 👋
Thank you for you comments!
Can you please refer us to a "proper" use case document, so that we have something to emulate?
Cheers

[iherman]

UCR documents can be quite extensive and complex, if one wants to do a thorough job; like, for example:

• Web Publications Use Cases and Requirements
• Use Cases and Requirements for Decentralized Identifiers
• Web Annotation Use cases (this is a wiki page with references, rather than a separate document)

These documents can be an overkill for this work, but it gives an idea of what should be there: list real use cases concentrating on one specific feature that is then needed and justifies its introduction. It helps if there is a table or a summary somewhere of the proposed new features.

[larscwallin]

Thanks Ivan 🙂 We'll make a more ambitious case for SyncMedia 👍

…

On Thu, 18 Feb 2021, 12:26 Ivan Herman, ***@***.***> wrote: UCR documents can be quite extensive and complex, if one wants to do a thorough job; like, for example: - Web Publications Use Cases and Requirements <https://www.w3.org/TR/pwp-ucr/> - Use Cases and Requirements for Decentralized Identifiers <https://www.w3.org/TR/did-use-cases/> - Web Annotation Use cases <https://www.w3.org/annotation/wiki/Use_Cases> (this is a wiki page with references, rather than a separate document) These documents can be an overkill for this work, but it gives an idea of what should be there: list real use cases concentrating on one specific feature that is then needed and justifies its introduction. It helps if there is a table or a summary somewhere of the proposed new features. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFTDP3GUDXTPA5DYCL2D5TS7T2OHANCNFSM4VEHTLQA> .