Re: EPUB and XML [was: The non-polyglot elephant in the room]

Henri,

> On Sat, Jan 26, 2013 at 2:29 PM, Michael[tm] Smith <mike@w3.org> wrote:
>>> But there is no fundamental requirement that EPUB version x+1 content be
>>> compatible with reading systems for EPUB version x,
>
> I'd be pretty unhappy if my EPUB Reading System for version x was
> rendered obsolete by EPUB x+1 ...Due to
> historical reasons, EPUB is on an XML track and the Web is not. Trying
> to unify them at this point would cause pain.

I might rephase that as "Due to historical reasons, SVG, MathML, and
EPUB are on an XML track, CSS and (increasingly) HTML are not". But
your general point is taken that there would be a non-trivial cost to
making future versions of EPUB incompatible with existing Reading
Systems. I was only expressing that there is no explicit "promise" of
backwards compatibility and indeed even today with EPUB 3 it's quite
easy to make a file that won't work properly on EPUB 2 Reading
Systems. Part of this is about how new capabilities are used...
various newer PDF capabilities will render files unreadable on older
PDF reading systems (e.g. using JPEG 2000 for images) but they
therefore tend not to get widely used for years after being deployed.
If an EPUB 4 supported non-XML HTML markup those who wanted content to
work everywhere obviously wouldn't move to it right away.

> (FWIW, the value for x is still 2 for ADE and Reader Mobile SDK-based
> systems. I think you are way too optimistic when it comes to updates
> to EPUB Reading Systems. It’s like IE6 all over again. These things
> don’t update every 6 weeks.)

You're correct about the historical situation with specialized
rendering engines for EPUB. But when EPUB 3 is widely deployed it's
clear that the platform's native browser engine (e.g. UIWebView on
iOS) will be widely used under the covers by reading systems - it is
already is by Apple iBooks, Kobo, and VitalSource Bookshelf. That
strategy has allowed e.g. iBooks to move much faster, e.g. at the same
rate that WebKit's changed on iOS. In some cases vendors may integrate
a browser engine like WebKit into their app (Kobo is doing so on
Android) but that so far seems to be motivated by the desire to move
faster in re: new versions than the underlying OS.

>>> & I see EPUB as simply the publication (portable document) packaging of
>>> the Open Web Platform.
>
> Weren't the W3C Widgets supposed to be that? As far as I can tell,
> characterizing EPUB like that is unhelpful scope creep their way
> adding videos, 3D and interactivity was for PDF.

I didn't think Widgets had tackled long-form publications among their
core use cases. But whatever Widgets was supposed to be it didn't get
traction so I don't think that's particularly relevant.

I'm not sure I understand your point re: scope creep. EPUB is now
starting to be used not just for commercial eBooks, but for academic
journals, corporate documentation (Cisco and IBM are now members of
IDPF for example), e-textbooks and other learning materials, etc. In
many cases the reason to adopt EPUB over PDF is to get benefits like
reflow and more structure content. In other cases it's precisely
because video and interactivity were bolted on to PDF in Adobe
proprietary ways that are fundamentally incompatible with how the Web
works, whereas EPUB is fundamentally built on the Web. Our
accessibility mission pushes EPUB towards satisfying as much of the
market's needs for reliable publications built on Web Standards as we
can rather than narrowly serving only one segment.

>> But as far as I understand it the case with current EPUB reading systems is
>> that they're all using browser engines to parse and render EPUB HTML
>> content, and those browser engines all already have HTML parsers.
>
> As far as I can tell, this is not true for the EPUB engine supplied as
> part of the Adobe Reader Mobile SDK which is currently either the most
> important our second most important EPUB engine (depending on how you
> judge importance relative to Apple’s engine)...

> ...Do you expect all the vendors who’ve shipped an embedded system with
> Reader Mobile SDK on it over the last 5 years or so to get a new
> engine from Adobe and push it to the customers...

The comment you responded to was not mine and you're right. But Adobe
has withdrawn their previously published roadmap for Adobe Reader
Mobile SDK to support EPUB 3 and seems to have effectively put it onto
a maintenance-only path, so naturally the various vendors using it now
are moving towards new solutions based on browser engines like WebKIt.
 So by the time an EPUB 4 could come about some years hence this would
be another story. since by then it will be true that  current EPUB
reading systems are universally using browser engines, and IMO will be
pushed to stay current in these engines by the same competitive
pressure that browsers are under. And by then we can see if the XML
serialization of HTML is still proving useful in other circumstances
besides EPUB. I don't think IDPF could or should carry on the torch of
XHTML all by ourselves just for packaged documents, so I'm just
suggesting that the long-term vector here is really up to HTML WG &
W3C.

--Bill

Received on Monday, 28 January 2013 15:04:54 UTC