search

w3c / sync-media-pub

Repository of the Synchronized Multimedia for Publications Community Group
http://w3c.github.io/sync-media-pub
Other
16 stars 4 forks source link

sync media file should declare which HTML document it goes with #26

Closed marisademeglio closed 3 years ago

marisademeglio commented 4 years ago

The text property is the only point of reference from sync media to HTML. It is currently defined as a URL fragment, e.g. #id1234

This fragment-only definition makes sense when the sync media file is discovered from within an HTML file. It can also make sense if the sync media file is discovered from data in a publication manifest, but only if the reading order item that it appears on is an HTML file.

If however it appears on an audio file item, we have no way of knowing the corresponding HTML document.

An Audiobooks processor encounters the following:

"readingOrder" : [{
        "type"  : "LinkedResource",
        "url"   : "audio/part001.wav#0",
        "encodingFormat" : "audio/vnd-wav",
        "name"  : "Chapter 1",
        "duration" : "457.931",
        "alternate" : "sync-media/part001-1.json"
},
...
]

But according to the current text definition, the text property would not say which file to open:

sync-media/part001-1.json:

...
{
 "text": "#id21",
 "audio": "file.mp3#t=23,45"
}
...

Ideas to fix this:

  1. Require* the filename on text 
    {
"text": "content.html#id21",
"audio": "file.mp3#t=23,45"
}

* -: it would probably be "technically optional" but given that Audiobooks is our most likely real-world use case, then we should be sure to write our examples in a way that will copy/paste well for that context.

  1. Add a property to the sync media file, at the root level, giving the filename. E.g. 
{
 htmlDoc: "content.html",
 narration: [
  {
   "text": "#id21",
   "audio": "file.mp3#t=23,45"
  },
  ...
 ]
}

and so the sync media file must say what HTML document it is using to synchronize with this audio file.

  1. (I don't really like this option but for completeness, here it is:)

Audiobooks should instead directly refer to the HTML document, which in turn refers to the sync media file from its <head>.

If we went this way, it would suggest that we could skip packaging sync media entirely and just always have the HTML refer to it. This to me feels like the easiest to specify and also the most cumbersome to author and maintain and process because 1. It increases the destructive editing burden on the HTML document, which I think we should be increasingly moving away from; and 2. Having to open an HTML document before you decide to fire up your sync media player is also additional processing burden.

marisademeglio commented 4 years ago

@danielweck thoughts?

danielweck commented 4 years ago

This fragment-only definition makes sense when the sync media file is discovered from within an HTML file. It can also make sense if the sync media file is discovered from data in a publication manifest, but only if the reading order item that it appears on is an HTML file.

See my thoughts / remarks on the "base URL" of the JSON document: https://github.com/w3c/sync-media-pub/issues/28

marisademeglio commented 3 years ago

The new draft is moving away from being so lightweight as to have this problem, so it may not be an issue in the end.