- From: Cramer, Dave <Dave.Cramer@hbgusa.com>
- Date: Thu, 3 Dec 2015 14:16:13 +0000
- To: Ivan Herman <ivan@w3.org>
- CC: Florian Rivoal <florian@rivoal.net>, Luc Audrain <LAUDRAIN@hachette-livre.fr>, W3C Digital Publishing IG <public-digipub-ig@w3.org>, Robin Berjon <robin@berjon.com>
On Dec 3, 2015, at 5:09 AM, Ivan Herman <ivan@w3.org> wrote: >> >> On 3 Dec 2015, at 11:01, Florian Rivoal <florian@rivoal.net> wrote: >> >> >>> On 03 Dec 2015, at 18:01, Ivan Herman <ivan@w3.org> wrote: >>> >>> >>> For my understanding: what this means that the 'index.html' (or 'nav.html') would not only be the TOC but something much more complex, essentially the cover page of the publication, right? One possibility is for index.html to represent the "cover page" that shows whatever the document creator wants. It could contain primary navigation but would more likely just link to the primary navigation document via link rel="contents". >>> >>> What this touches upon is my question the other day, which is still something to discuss: if the URL 'U' identifies the PWP, what does a HTTP GET return? My approach, up to now, was that the return would be the manifest. In your case, would it be the index.html that links to the manifest? >> >> This is where I show how naïve I am... >> >> Why cannot index.html be the manifest (while being the cover page etc at the same time)? We'd need additional conventions beyond the normal semantics of HTML, what's wrong with that? I think of a manifest as information that's only of interest to computers, not humans. And so HTML may not be the most natural way to structure that information. And I'm still hopeful about taking advantage of the web app manifest spec. > > It could. Except that the manifest file may become fairly large, and editing it as part of an HTML file (at least for human editor) may become cumbersome. Agreed. > > If we go down that road, I would still prefer to settle on the index file with a link to the manifest (an option that Dave had on his slides), just for reasons of maintenance. Also, manifests are often handled by dedicated javascript routines; a manifest in JSON is quicker and easier to digest than, say, if all information is encoded into RDFa as part of the index file. Agreed. > > (Another alternative, and this should not be excluded, is to embed a manifest in JSON as a <script> tag in the HTML file. For shorter manifests this may be fine.) Interesting. But ideally we'd have a single convention on how to find the publication's manifest. > > Ivan > > >> >> As far as I understand, that's the approach taken by scholarly HTML, and the one that epub0 was advocating. I do think of the manifest as being a separate problem from determining the sequence of files in a publication (what is confusingly called the "spine" in EPUB3). EPUB Zero has proposed using the primary navigation element to determine that sequence, but I'm starting to think that the most flexible approach is to just use HTML link relationships, as that's what they were made for :) Thanks, Dave This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
Received on Thursday, 3 December 2015 14:16:44 UTC