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

> 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

[2]
https://w3c.github.io/publ-epub-revision/epub32/spec/epub-ocf.html#sec-conta
iner-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/
mobile: +31-641044153

ORCID ID: https://orcid.org/0000-0003-0782-2704