Re: DPUB module comments

> Might DPUB define this as an id?
> <nav id="landmarks">

It'll be hit and miss whether an approach like that could work. Maybe for 
the landmarks since in EPUB it's a component of the navigation document, but 
there aren't that many niche cases.

What I find problematic is that pinning semantics to IDs ultimately intrudes 
into the authoring sphere, and tries to layer meaning where it wasn't 
intended. Did the author want to identify a structure, or did they just 
happen to use an ID that matches a specification requirement they may not 
have been aware of? That's why we have the epub:type attribute.

Publishers are typically also using their own identification systems for 
content (think CMS and content aggregation), so pushing simple ID naming 
conventions is going to prove problematic, as it forces the content creators 
to fall back on the kinds of models (epub:type) that we're trying to move 
away from.

And it will lead to conflicts. A work as a whole might have a table of 
contents, but then every section within it might also have a table of 
contents at the start. Now you're forced to break your content up into 
separate documents to avoid naming conflicts, even if it's not what you 
want.

But to try and make a long story shorter, it was discussed and agreed at the 
last call that the name "landmarks" is problematic, so the ball is back in 
Markus, Tzviya and my court to fix that role. At the very least, that name 
won't be in the final vocabulary list. And hopefully we'll have a definition 
that doesn't sound so much like a generic nav.

Matt

Received on Tuesday, 17 March 2015 13:36:28 UTC