Re: Ideas for the next draft

Hi Makoto,

That’s a good idea, we should collect all our requirements notes and stray thoughts into a single document. Thanks for that suggestion. 

We have not adopted a design principles document. Having a compact syntax has long been desirable and it’s still in the front of my mind. 

Creating synchronized text/audio contents is still a lot of work and I think this is the barrier to adoption, not the format we use to represent it in the end. Perhaps some examples for our proposed additional features will help to increase usage as it will show more situations where this type of tech makes sense. Stay tuned!

Thanks
Marisa

> On Jul 23, 2020, at 15:38, MURATA Makoto <eb2m-mrt@asahi-net.or.jp> wrote:
> 
> Marisa,
> 
> Are there requirement documents?  
> 
> Do you have a design principle document?
> SMIL has a long history and MO has some success.  
> This reminds me of CORBA and SOAP.  CORBA 
> was too complicated.  SOAP started as a much 
> simpler protocol.  But eventually, WS-* became 
> as complicated as CORBA.  REST is now widely 
> adopted, although it does not even try to be feature-rich.
> How can we avoid the failure of  CORBA and Web 
> Services?
> 
> Regards,
> Makoto
> 
> 2020年7月17日(金) 5:51 Marisa DeMeglio <marisa.demeglio@gmail.com <mailto:marisa.demeglio@gmail.com>>:
> Hi all,
> 
> I’d like to present some new ideas for Synchronized Narration. This addresses several of our open issues and I believe gives us a more robust and flexible spec on which to build future iterations of our work.
> 
> The key points are:
> 
> 1. Separate media asset declaration from in-presentation usage
> 
> Reasons:
> * Less verbose file: don't need to redeclare file srcs every time the media asset is used.
> * Enable #2 (below)
> 
> 2. Ability to express properties on assets, e.g. custom highlight class, which can be overridden in the presentation.
> 
> Reasons:
> * We had been looking at different ways to declare the default highlight class name. 
> * The idea outlined in the current draft is not tenable (see issue https://github.com/w3c/sync-media-pub/issues/21 <https://github.com/w3c/sync-media-pub/issues/21>). 
> * Having default properties on assets is a more generic approach.
> 
> 3. Ensure nesting supports not only semantic structures, but also nested highlights
> 
> Reasons:
> * Nesting has always been a requirement for us. This just refines how it works. 
> * Nested structures still possible for enabling an escape feature (to let a listener “escape” out of a complex table and back to the main content)
> * An example of a nested highlight would be to highlight a paragraph by changing its background color, and highlighting each span as it plays, by changing the text foreground color. We can now do this with nesting and properties.
> 
> 4. Consider using XML instead of JSON
> 
> Reasons:
> * When the above changes are in place, JSON becomes unwieldy, and not at all the compact syntax we were going for.
> * Idea to provide a JS library to transform an XML document into a JSON data structure, to keep the web developers happy.
> 
> There is a short writeup of the new ideas here [1].
> 
> And just to remind you, here's our current draft [2], which needs updating, and issues list [3]. The proposal here would sort out many of those issues.
> 
> Thanks to Lars Wallin at Colibrio for sharing ideas and contributing to these new drafts. Looking forward to hearing everyone's thoughts as we go further.
> 
> Thanks
> Marisa
> 
> 1. https://github.com/w3c/sync-media-pub/blob/master/drafts/sync-narr-xml.md <https://github.com/w3c/sync-media-pub/blob/master/drafts/sync-narr-xml.md>
> 2. https://w3c.github.io/sync-media-pub/synchronized-narration.html <https://w3c.github.io/sync-media-pub/synchronized-narration.html>
> 3. https://github.com/w3c/sync-media-pub/issues <https://github.com/w3c/sync-media-pub/issues>
> 
> 
> 
> -- 
> Regards,
> Makoto