Re: Ideas for the next draft

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 <mailto:lars@colibrio.com>>
> Date: Thursday, 23 July 2020 at 08:45
> To: Avneesh Singh <avneesh.sg@gmail.com <mailto:avneesh.sg@gmail.com>>
> Cc: Marisa DeMeglio <marisa.demeglio@gmail.com <mailto:marisa.demeglio@gmail.com>>, W3C Synchronized Multimedia for Publications CG <public-sync-media-pub@w3.org <mailto:public-sync-media-pub@w3.org>>, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>
> Subject: Re: Ideas for the next draft
> Resent from: <public-sync-media-pub@w3.org <mailto: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 <mailto: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 <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 <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 issuehttps://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>
>>>  
>> 
>>  
> 
> 
>  
> ----------------------------
> 
> http://www.bbc.co.uk <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.
> ---------------------