Re: Ideas for the next draft

Absolutely Marisa! It's looking good 🙂

On Thu, 23 Jul 2020, 18:07 Marisa DeMeglio, <marisa.demeglio@gmail.com>
wrote:

> Hi all,
>
> Yes, let’s definitely look at the abstract model first, and then choose a
> serialization format. Obviously I have thoughts about the latter, which
> I’ve shared with you, but let’s go through it methodically first.
>
> So, go back to this document:
>
> https://github.com/w3c/sync-media-pub/blob/master/drafts/sync-narr-ideas.md#concepts
>
> (renamed to remove “xml” from the filename just so that doesn’t distract).
>
> The “Concepts” section is not tied to any serialization format. So can we
> start with what’s there?
>
> Thanks
> Marisa
>
> On Jul 23, 2020, at 06:23, Laurent Le Meur <laurent.lemeur@edrlab.org>
> wrote:
>
> Hi everyone,
>
> I like Lars's idea about getting first a consensus on the model, then only
> speak about serialization.
>
> The only issue is to choose a proper "schema" (as Lars says), i.e. a way
> to express this model if I understand well.  WebIDL was used for Web
> Publications and the Publication Manifest
> <https://www.w3.org/TR/pub-manifest/#webidl> but is not loved by
> everyone. Simple property tables may be largely sufficient (see an example
> here <https://www.w3.org/TR/pub-manifest/#value-linked-resource>).
>
> I'm much less enthusiastic about the possibility to define several
> recommended serializations; if servers have a choice, clients will have no
> choice other than supporting all possible flavors, with all associated
> incomplete implementations, bugs etc. as usual.
>
> Bien à vous,
>
> Laurent /EDRLab
>
>
> Le 23 juil. 2020 à 13:12, Nigel Megitt <nigel.megitt@bbc.co.uk> a écrit :
>
> 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.
>
> +1000
>
>
> *From: *Lars Wallin <lars@colibrio.com>
> *Date: *Thursday, 23 July 2020 at 08:45
> *To: *Avneesh Singh <avneesh.sg@gmail.com>
> *Cc: *Marisa DeMeglio <marisa.demeglio@gmail.com>, W3C Synchronized
> Multimedia for Publications CG <public-sync-media-pub@w3.org>, Ivan
> Herman <ivan@w3.org>
> *Subject: *Re: Ideas for the next draft
> *Resent from: *<public-sync-media-pub@w3.org>
> *Resent date: *Thursday, 23 July 2020 at 08:45
>
> 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
>
>
>
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> ---------------------
>
>
>
>