W3C home > Mailing lists > Public > public-digipub-ig@w3.org > February 2017

Re: [charter] statement on EPUB4

From: Laurent Le Meur <laurent.lemeur@edrlab.org>
Date: Wed, 15 Feb 2017 09:21:21 +0100
To: W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-Id: <2CCB1677-3336-480A-886E-0556CB2A82A5@edrlab.org>
I like Matt's proposal of a "rountrip" concept, with some caveats. 
The internal plumbing of the future EPUB revision may be different and its functional coverage may be larger. 
What may happen is that a functionality which is "easy" to implement in EPUB 4 appears more convoluted when ported back to EPUB 3 (I'm thinking about audiobooks), or may present some functional loss (think about page transitions in digital comics).    

Laurent Le Meur, EDRLab

> Le 14 févr. 2017 à 20:30, Matt Garrish <matt.garrish@gmail.com> a écrit :
>>> higher degree of comprehensive accessibility capabilities and reliability
>> Things that might be optional (or perhaps not even included in the base spec)
>> may/will be mandated by this profile.  (No, I don’t have a good example, but it
>> seems like something worth calling out)
> The progressive enhancement requirement in EPUB 3, perhaps? This makes the publication more reliably usable, which was discussed on the last call may not be a base requirement of web publications when offline. Not sure if that's what reliability is after here, but that's my best read relative to EPUB.
>>>> with incompatibilities minimized.
>>>   What does ³incompatibilities minimized² mean? 
>> I don’t think it means anything technically at this point, just a 
>> statement of direction (that could probably use a bit of wordsmithing).
> Isn't this the same general constraint we had for BFF? Should be possible to round trip formats as much as possible. Maybe it should say as much, so something like:
> "This specification should be as close as possible to a strict functional superset of EPUB 3.1, allowing translations between the two formats with as minimal loss of functionality as possible."
> Matt
Received on Wednesday, 15 February 2017 08:21:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:37 UTC