W3C home > Mailing lists > Public > public-publ-wg@w3.org > December 2018

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

From: Ivan Herman <ivan@w3.org>
Date: Wed, 12 Dec 2018 09:23:19 +0100
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>
Message-Id: <55C5FDD5-5496-43B8-B877-2F2AFB1CFC97@w3.org>
To: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
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>


Received on Wednesday, 12 December 2018 08:23:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:33 UTC