Open iherman opened 3 years ago
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:
epub:type
, which wanted to be called role
but we were told not to use role
at that timeepub:textref
, but rather supports multiple parallel text referencesparam
to control styling; MO uses metadata in the package doc and offers far less flexibility<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 -
sync:
extensions still considered a valid SMIL3 document?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.
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
UCR documents can be quite extensive and complex, if one wants to do a thorough job; like, for example:
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.
Thanks Ivan 🙂 We'll make a more ambitious case for SyncMedia 👍
On Thu, 18 Feb 2021, 12:26 Ivan Herman, notifications@github.com 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 https://github.com/w3c/sync-media-pub/issues/35#issuecomment-781277008, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFTDP3GUDXTPA5DYCL2D5TS7T2OHANCNFSM4VEHTLQA .
§2 touches upon this, but it only says:
At some point in time, this section should be much more explicit. There are some questions to be answered:
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.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.