EPUB Module: Landmarks

[jccr]

How should someone try to understand Landmarks in the model?

(refresher: http://kb.daisy.org/publishing/docs/navigation/landmarks.html)

Two ideas:

1. Should we map epub:type enum values into the definition ofLinks in the landmarks (and friends) subcollections?

It could be that we use rel for epub:type values.. Here's my proposed solution:

  "landmarks": [
    {
      "rel": "cover",
      "href": "cover.xhtml",
      "title": "Cover"
    },
    {
      "rel": "titlepage",
      "href": "copyright.xhtml#title",
      "title": "Title Page"
    },
    {
      "rel": "toc",
      "href": "tox.xhtml#TOC",
      "title": "Table Of Contents"
    },
    {
      "rel": "bodymatter",
      "href": "chapter1.xhtml",
      "title": "Start Of Content"
    }

Note that we already have cover as a rel: https://readium.org/webpub-manifest/relationships.html#:~:text=cover

2. Should we just point to the landmarks nav element in the model, and the processing happens outside of the model?

How would that look like? I believe this is how I understood your alternative, @HadrienGardeur.

Use Cases

The DAISY Knowledgebase article highlights this use case:

Not only does the landmarks nav simplify access to major sections of the publication, without having the navigate the entire table of contents, but it also facilitates user agent behaviors. A device that gives the option to automatically open to the first page of the body, for example, or provides quick links to the index or glossary can make use of the extra semantics in the landmarks nav to this end.

My use case is that I want a model (implemented in code) to read this information and expose it as a Publication model instance. My users are consumers of this, let's say via an API, which could be using this information to understand the major sections of a book.

[jccr]

Also as of the moment, I am unable to see the relationship to this and loi, lot, etc. I don't have concrete examples that use these listings in the EPUBs I have on hand.

[mickael-menu]

Personally I prefer solution 1, and it's already exposed like that on mobile since it's part of the EPUB extension of RWPM. However, epub:type is ignored in the parsing.

Putting it in rel makes sense, but maybe we could fully qualify the values, so http://www.idpf.org/2007/ops#cover?

http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-content-type-attribute

[jccr]

Personally I prefer solution 1, and it's already exposed like that on mobile since it's part of the EPUB extension of RWPM. However, epub:type is ignored in the parsing.

Putting it in rel makes sense, but maybe we could fully qualify the values, so http://www.idpf.org/2007/ops#cover?

http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-content-type-attribute

Interesting idea, I'm ok with that.

@HadrienGardeur ?

[HadrienGardeur]

It's not "Solution 1 OR 2" but very much "Solution 1 AND 2":

• I still think that it's a good idea to map epub:type to rel values and have them available in toc, landmarks and similar collections
• we'll need a mapping for that, where some of these values are mapped to existing rel values while others will require a URL (as @mickael-menu has already pointed out)
• this should be documented in our EPUB parsing document IMO which we'll need to rename slightly
• we already identify the Navigation Document using the contents rel value in our manifest, which means that apps are also free to access and parse that document

[jccr]

I found the overlap between EPUB and IANA link relations:

• appendix
• chapter
• glossary
• help
• index

[jccr]

Seeing as this list is small.. is it practical to have a map at all? I say let's require a URL for all values, including http://www.idpf.org/2007/ops#cover, http://www.idpf.org/2007/ops#appendix , http://www.idpf.org/2007/ops#chapter, http://www.idpf.org/2007/ops#glossary, etc