Re: OCF for Packaging (was Re: [AudioTF] Agenda 2018-12-14)

>  Is it to use an OCF-Lite packaging purely for experimental purposes while web packaging evolves,

It would be ignoring industrial reality. OCF-lite solution will be put in place and will survive at least as a B2B interchange format after Web Packaging is released. Conclusion: this is NOT experimental, this is industrial. 

Many on the industry side of this group think that Web Packaging will bring nothing to publication that are not "born on the Web", and that OCF-lite (of OCF 3.2 or OCF 4 if we prefer) is good enough for this use case (both B2B interchange and B2C download). 

Laurent Le Meur
EDRLab

> Le 12 déc. 2018 à 16:55, Matt Garrish <matt.garrish@gmail.com> a écrit :
> 
> > and we will come back to the issue when a Web Packaging standard exists
>  
> I’m not sure I follow the proposal. Is it to use an OCF-Lite packaging purely for experimental purposes while web packaging evolves, or to release a specification knowing that the packaging part of it is probably replaced in the future? If it’s the latter, is it realistic authors/developers are going to invest in a specification with a big hole of uncertainty around it? As Ric often brings up, once you release you can’t walk back again on support, so you’re stuck with a two-headed monster.
>  
> Matt
>  
> From: Ivan Herman <ivan@w3.org> 
> Sent: December 12, 2018 04:23
> To: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
> Cc: Wendy Reid <wendy.reid@rakuten.com>; Laurent Le Meur <laurent.lemeur@edrlab.org>; Leonard Rosenthol <lrosenth@adobe.com>; Benjamin Young <byoung@bigbluehat.com>; Avneesh Singh <avneesh.sg@gmail.com>; Brady Duga <duga@google.com>; Garth Conboy <garth@google.com>; W3C Publishing Working Group <public-publ-wg@w3.org>
> Subject: Re: OCF for Packaging (was Re: [AudioTF] Agenda 2018-12-14)
>  
> I would propose that we put the admin issues (rec or not rec, etc) aside for a moment. Although I am far from being an expert, my feeling is:
>  
> On long term, Web Packaging is probably the optimal solution, because it takes care of a number of issues around Web related problems like security, URL usage, origin, and all that jazz. However, that is down to, say, 2020-2022, and we need a, possibly temporary, solution now that can be used by our modules.
>  
> As that temporary solution, we could define an OCF "Lite". I do not have a good technical knowledge about this, but after a cursory look at the 3.2 OCF document[1] it looks like we only need to look at section 3 and, possibly, throw away most of what is there:-). As a first reaction, I would say we need an agreed-upon name for the HTML Primary Entry page (say, "index.html") and that is maybe _all_ what we need. (I presume we would be silent, for now, on the encryption related entries).
>  
> It strikes me that such an OCF Lite would be the closest to the current deployment of the industry, and would make the transition easy; all other technologies that were listed would be way more (too?) radical. We can even make it clear to the community that this is a temporary measure (which may mean we do not define OCF Lite as a Recommendation for now) and we will come back to the issue when a Web Packaging standard exists.
>  
> How does that sound?
>  
> Ivan
>  
>  
> [1] https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html <https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html>
> [2] https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html#sec-container-metainf-files <https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html#sec-container-metainf-files>
> 
> 
>> On 12 Dec 2018, at 00:00, Hadrien Gardeur <hadrien.gardeur@feedbooks.com <mailto:hadrien.gardeur@feedbooks.com>> wrote:
>>  
>> > An unpackaged audiobook that can be opened in a web browser, that can be packaged easily for distribution to a retailer, then on the user side either consumed in the packaging in a specialized user agent or without it in a vanilla browser seems very possible to me if we put our collective minds to it.
>> 
>> There's nothing that a Web browser can open right now in 2018 and given the pace of working on a standard and getting implementations, I doubt that things will dramatically change in 2019 or 2020 (hence the 2022 horizon that I was pointing at).
>> 
>> In the meantime, we're stuck with something less than ideal on the Web (ZIP or one of the variants that we're discussing) but that can still work in a Web app with a mixed of partial range requests and JS.
>> Is that what you meant by "usable on the Web"?
>> 
>> If not, I'm sorry but given the current charter for this WG, this is indeed a pipe dream.
> 
>  
> 
> ----
> Ivan Herman, W3C 
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153
> ORCID ID: https://orcid.org/0000-0003-0782-2704 <https://orcid.org/0000-0003-0782-2704>