- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 06 May 2011 17:24:12 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Leonard Rosenthol <lrosenth@adobe.com>, Henri Sivonen <hsivonen@iki.fi>, "tmichel@w3.org" <tmichel@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
On May 6, 2011, at 4:14 PM, Silvia Pfeiffer wrote: > On Sat, May 7, 2011 at 1:20 AM, Leonard Rosenthol <lrosenth@adobe.com> wrote: >> EPUB3 is based on the XML serialization of HTML5+CSS (<http://idpf.org/epub/30/spec/epub30-overview.html>) and as such uses the same UA's (especially WebKit-based ones). In addition, because it is simply a packaging of (X)HTML5 plus associated resources, it can indeed be placed on a server and transparency served up. > > > I'm not going to elaborate this any further, but once you package it > with additional resource and give it a different name, you have > created a new resource type that is not "just supported" by UAs. It's > not Web content any more. *Something* (e.g. a plugin, a Web > application) has to unpack it first before handing the individual > pieces one at a time to a UA for interpretation. If you unpack an epub archive, you can load the HTML file inside it in a browser. This is useful to do at times, for example for testing purposes. I have no specific opinion on whether this is a critical use case. As others have mentioned, it is also possible to build an EPUB reader using Web technologies. Note: even though in the EPUB case there is generally not a server involved, it is the case that an EPUB contains a fixed set of resources and any required metadata about them could be precomputed. However, for data that is available by introspecting a media file on the server side, or ahead of time when packaging a resource such as an EPUB book, there may be reasons it is more convenient to gather the data at runtime in the client. For example, it may be desirable to build reusable libraries that handle arbitrary media objects and make use of particular metadata. If that metadata must be extracted server-side or up front, then these libraries will need to define a format for transmitting that data to the client, so a library can make use of it. It would be regrettable if such a separate format had to be invented, since the data is already in the media file itself. For reasons such as these, I'm skeptical of "you can do that server-side" as a sufficient answer, if there are in fact valid use cases for the metadata in question. I will concede at this point that I haven't followed the thread enough to know what specific metadata is under discussion, and what if any use cases there are for it. Regards, Maciej
Received on Saturday, 7 May 2011 00:24:56 UTC