Re: Ideas for the next draft

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>:

> 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).
> * 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
> 2. https://w3c.github.io/sync-media-pub/synchronized-narration.html
> 3. https://github.com/w3c/sync-media-pub/issues
>
>

-- 
Regards,
Makoto