- From: Markku Hakkinen <mhakkinen@acm.org>
- Date: Fri, 6 May 2011 14:01:45 +0300
- 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 Fri, May 6, 2011 at 10:14 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > As you correctly state: a specialised HW or SW eBook reader is > required. A vanilla browser cannot display the eBook and requires a > plugin. I did not use the term "required". I gave one example of eBook readers which embed HTML rendering engines. There is another approach, which I neglected to mention. Using DAISY publications as a use case, I have just consulted with a developer of a DAISY book reader, running as a Javascripted application within a plain vanilla browser. No plugin is required, given the capabilities inherent in HTML and Javascript. When asked about a metadata API, the answer was that it would be very useful to them, and it would be used, if available. > > Once you are at the plugin level, you can provide all sorts of > additional functionality such as extracting metadata. > But plugins do not appear to be the trend among the talking book organizations creating book players for the Web. > This is not a use case to introduce a metadata API into HTML. I disagree, and will ask the developers to submit specific requirements. Mark > > On Fri, May 6, 2011 at 5:02 PM, Markku Hakkinen <mhakkinen@acm.org> wrote: >> The ePub 3.0 document content model is HTML5. HTML5 UA's will be used >> to render ePub publications, embedded in hardware or software eBook >> readers. Note that ePub is a container (like ZIP) that contains HTML5 >> content and associated resources, which may include any audio and >> video referenced in the content. In the eBook world, content is >> downloaded and read on a local device. >> >> mark >> >> >> >> On Fri, May 6, 2011 at 4:39 AM, Silvia Pfeiffer >> <silviapfeiffer1@gmail.com> wrote: >>> EPUB is not HTML, so it does not get interpreted by a HTML UA and >>> therefore not exposed through the HTML IDL. Even if there is HTML >>> somewhere in EPUB, you are not delivering a HTML file to the Web >>> browser but an EPUB file. If you want to interpret EPUB markup in a >>> Web browser you need a plugin. >>> >>> Silvia. >>> >>> On Fri, May 6, 2011 at 1:32 AM, Leonard Rosenthol <lrosenth@adobe.com> wrote: >>>> HTML is a markup language that can be (and is!) used in MANY DIFFERENT areas. To limit it (and it's design/development) to the "Web" is short-sighted and will only lead to interoperability problems in the future. >>>> >>>> Leonard >>>> >>>> -----Original Message----- >>>> From: Henri Sivonen [mailto:hsivonen@iki.fi] >>>> Sent: Thursday, May 05, 2011 12:37 AM >>>> To: Leonard Rosenthol >>>> Cc: Silvia Pfeiffer; tmichel@w3.org; public-html@w3.org; public-media-annotation@w3.org >>>> Subject: RE: follow up on the discussion in HTML5 about metadata access >>>> >>>> On Wed, 2011-05-04 at 16:52 -0700, Leonard Rosenthol wrote: >>>>> > Right now, all use cases discussed on the HTML WG list were solvable >>>>> > with server-side APIs. >>>>> > >>>>> That is NOT true, Silvia! >>>>> >>>>> I raised a number of use cases for non-browser-based UAs - for example >>>>> EPUB viewers - where server-side was NOT an option. >>>> >>>> Why would an .epub book need to be able to introspect its own metadata >>>> using a script? >>>> >>>> As for viewers, if the viewer wants to do stuff with metadata, it can >>>> implement whatever interfaces it wants for its own private use. They >>>> don't have to be standardized or exposed to scripts provided by the book >>>> itself. >>>> >>>> (I tend to get skeptical when a Web API is motivated by non-Web uses. >>>> The W3C has been down that road before. Has it ever been a good road?) >>>> >>>> -- >>>> Henri Sivonen >>>> hsivonen@iki.fi >>>> http://hsivonen.iki.fi/ >>>> >>>> >>> >>> >> >
Received on Friday, 6 May 2011 11:05:26 UTC