Re: Moving forward with sync media work

Thanks for commenting! Replies inline.

> On Oct 18, 2018, at 1:01 AM, Romain <rdeltour@gmail.com> wrote:
> 
> Hi,
> 
> Thanks for sharing, the documents are very informative!
> 
> A couple minor comments:
> 
> 1. The use cases document says:
>> Text chunks are highlighted in sync with the audio playback, at the authored granularity
> 
> This implies that the granularity _is_ authored. Sometimes, the sync could be generated on the fly, with sentence and/or word detection. Do we want to cover this use case too?

So in this use case, a reading system gets a publication with some coarse level of synchronization (e.g. paragraph), and it provides, on the fly, finer granularities (word or sentence)? Are there tools that do this now? Not necessarily with audio ebooks but with any similar-enough types of content?

> 
> 2. One of the additional requirements is:
>> be able to be validated
> 
> This has been indeed very important in the historical EPUB context, where most ingestion pipelines require EPUBs to be valid. On the Web this is less important; I think what is critical however is that the technology is _testable_ (to increase interoperability) and with good error handling (what a UA must do when the author didn't follow the spec).
> 

Agree that UA error handling guidelines are important. How would you define/describe testability in our context? 

To me, validation is a separate concern —  whatever format we produce to represent sync media should be validate-able. Not saying what the validation result should be used for, just that it should be possible to validate.

To put in context, I’ve gotten several suggestions over the year(s) of “why don’t you just use javascript” to create sync media books, and the answer always is that we want a declarative syntax, one of the reasons why being that it can be validated and migrated forward. 

> 3. One of the additional requirements is:
>> CSS "active" class (for highlighting the currently playing HTML element)
> 
> This implies an implementation decision to go with a dynamically enabled special class. We could potentially envision other options however, for instance using a CSS pseudo-class (like `:current`, being drafted in Selectors Level 4).
> For now I would reformulate the requirement to something like "the highlight must be stylable with CSS", to make it a bit more independent from the implementation.

Good point, we could make this more generic at the requirement level. 

> 
> That's all! :-)
> 
> Romain.

Same :)  

Marisa

> 
>> On 16 Oct 2018, at 21:08, Marisa DeMeglio <marisa.demeglio@gmail.com <mailto:marisa.demeglio@gmail.com>> wrote:
>> 
>> Hi all,
>> 
>> Daniel and I are moving forward with a sync media solution, and we want to point out some new documents on the CG's github that describe the use cases and technology selection process. I looked into several pre-existing potential solutions, hoping to have a discussion here on the list about our various options; and in the process of narrowing down our choices, I found nothing suitable. That leaves us with creating our own as a viable route. 
>> 
>> 1. Scoped use cases: 
>> https://github.com/w3c/sync-media-pub/blob/master/use-cases.md <https://github.com/w3c/sync-media-pub/blob/master/use-cases.md>
>> 
>> 2. Additional requirements:
>> https://github.com/w3c/sync-media-pub/blob/master/addl-reqs.md <https://github.com/w3c/sync-media-pub/blob/master/addl-reqs.md>
>> 
>> 3. Technology selection process:
>> https://github.com/w3c/sync-media-pub/blob/master/technology-selection.md <https://github.com/w3c/sync-media-pub/blob/master/technology-selection.md>
>> 
>> Next up will be a proposed syntax, to be posted on this list in the coming days. 
>> 
>> Thoughts, comments, general discussion? It would be great to hear from you all.
>> 
>> Thanks
>> Marisa
>