Re: Ideas for the next draft

Hi everyone 👋

I just wanted to say something regarding data types vs encoding of data
types.

In order to not let encoding type (XML, JSON, ...) get in the way of
further discussions and development, I suggest that any schema that we
produce is explicitly neutral in terms of the encodings that will be used
to serialize their data types.

This way we will be able to focus on design and later in the process decide
one or more recommended types of encoding to be used.

I would also suggest not using JSON-LD for schemas as it is far from
optimal for purposes such as describing data types in a domain model. I
think we should consider using a more unambiguous way of describing our
data structure and types. Not sure what would be the best format though.
Maybe WebIDL?

Ciao,
Lars

On Wed, 22 Jul 2020, 06:26 Avneesh Singh, <avneesh.sg@gmail.com> wrote:

> Hi Marisa,
>
> I could not go through your documents yet, mainly because of W3C AB
> meetings and other things that required my attention in this week.
> As soon as I come back to technical world, I will get in touch with you
> and Daniel to discuss this well.
>
> With regards
> Avneesh
> *From:* Marisa DeMeglio
> *Sent:* Wednesday, July 22, 2020 2:58
> *To:* W3C Synchronized Multimedia for Publications CG ; Lars Wallin ; Ivan
> Herman ; Avneesh Singh
> *Subject:* Re: Ideas for the next draft
>
> I wonder if anyone has had a chance to look at the document I sent around
> about some new ideas, specifically the part about how these new concepts
> might look if we used a SMIL-ish syntax [1].
>
> I’m saying “SMIL-ish" rather than “actual SMIL”, because strictly
> speaking, SMIL does not cover everything that we want to do (and also, it
> has tons of stuff we don’t need). Waking up that WG and adding new elements
> is more than I’m ready for; however, borrowing some of their elements and
> adding enhancements seems entirely reasonable.
>
> I would also like to note the future of EPUB, in a new WG, which has among
> its deliverables Media Overlays 3.x [2].
>
> So rather than veer off in a new format direction, what if we proposed the
> work of this CG as an evolution of Media Overlays? That way, there’s a
> coherent thread among EPUB 3, Audiobooks, and EPUB Next.
>
> Copying Ivan and Avneesh because I’d really like to hear their thoughts.
>
> Thanks
> Marisa
>
> 1. https://github.com/w3c/sync-media-pub/blob/master/d
> rafts/sync-narr-xml.md#notes-about-smil
> <https://github.com/w3c/sync-media-pub/blob/master/drafts/sync-narr-xml.md#notes-about-smil>
> 2. https://w3c.github.io/epub-3-wg-charter/#deliverables
>
> On Jul 16, 2020, at 13:51, Marisa DeMeglio <marisa.demeglio@gmail.com>
> wrote:
>
> 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
>
>
>
>