RE: [AudioTF] Agenda 2018-12-14

> I'm actually surprised how much these discussions are focused on mimetype rather than on the other requirement for OCF: the presence of META-INF/container.xml

 

Isn’t that because the suggestion was made that OCF 3.2 could be hacked at to make this new packaging viable without producing a new standard? I don’t agree with the approach (modifying OCF 3.2), because the impacts on reading systems (and elsewhere) are obviously real, but it seems like the only “lite” change that might have been feasible. Making the container.xml file optional within EPUB 3 would certainly break things.

 

But if the end goal is to produce a different standard, then I suppose anything is doable. Aside from EPUB not having a common path/naming for the package file, the only other feature it enabled was pointing at multiple renditions of the content. But that has never taken off.

 

Matt

 

From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com> 
Sent: December 13, 2018 19:11
To: Brady Duga <duga@google.com>
Cc: Leonard Rosenthol <lrosenth@adobe.com>; Ric Wright <rkwright@geofx.com>; Dave Cramer <dauwhe@gmail.com>; Matt Garrish <matt.garrish@gmail.com>; W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: [AudioTF] Agenda 2018-12-14

 

I'm actually surprised how much these discussions are focused on mimetype rather than on the other requirement for OCF: the presence of META-INF/container.xml

 

Since we would have well-known locations both for the entry page (index.html) and the manifest (manifest.jsonld), does anyone have a good reason why META-INF/container.xml should remain a requirement?