Is this list dead?

[Baldur Bjarnason]

And if so, where am I supposed to send feedback?

Or aren't people interested in that sort of thing?

I see several issues with e0 as it is proposed on the infogridpacific site (http://www.infogridpacific.com/blog/igp-blog-20130717-e0-test-set1-ready.html). A lot of them are outlined in my earlier post to this list (https://groups.google.com/forum/#!topic/epub-ng/xTvgvsNVc6w) but there is at least one more that I didn't mention there.

Namely this:

if role="spine" means that something is in the spine?

And role="toc" means that something is in the toc?

Then how in $deity's name can role="toc spine" mean that something is in neither? (as per http://apex.infogridpacific.com/df/df20130717-e0-packaging-1.html)

e0 has plenty of ambiguities. Cover handling for starters. The toc+spine issue above for seconds.

- best

- baldur

[Dave Cramer]

The idea is that the default is for an element to appear in both spine and toc, so role="spine toc" would be [1] redundant and [2] mean that something appears both in spine and in default navigation. role="toc" means not in spine, role="spine" means not in toc. It's not elegant, but it seems much better than having multiple navigation structures to convey both types of information.

Haven't had a chance to read the IGP blog post yet.

Cover handling is undefined as far as I know.

I like the idea of having an implementation before the spec. We have a chance for practice, as well as theory, to influence what happens.

Dave

[Alberto Pettarin (alberto@albertopettarin.it)]

On 07/18/2013 06:15 PM, Dave Cramer wrote:
> The idea is that the default is for an element to appear in both spine
> and toc, so role="spine toc" would be [1] redundant and [2] mean that
> something appears both in spine and in default navigation. role="toc"
> means not in spine, role="spine" means not in toc. It's not elegant, but
> it seems much better than having multiple navigation structures to
> convey both types of information.

Wouldn't be the following more natural?

role="" (or omitted) => NOT in TOC, NOT in spine
role="toc" => in TOC, NOT in spine
role="spine" => in spine, NOT in TOC
role="spine toc" or role="toc spine" => in spine, in TOC

This implies adding role="spine toc" to most items, but it's trivial
both for index.html generated via code and for index.html hand-coded
(copy-and-paste) and the space wasted is negligible. I would strongly
prefer keeping the logic of role "additive", which (to me) seems easier
for both the eBook producer and the index.html parser.

Cheers,

AlPe

[Hadrien Gardeur]

if role="spine" means that something is in the spine?

And role="toc" means that something is in the toc?

Then how in $deity's name can role="toc spine" mean that something is in neither? (as per http://apex.infogridpacific.com/df/df20130717-e0-packaging-1.html)

I believe that only spine should be mandatory.

If no ToC is provided, then we could build it using the text nodes provided in spine.

If a ToC is also provided, then the RS should use that element.

Parsing the text nodes of a spine is much easier than creating a spine out of a ToC. For example, the same document could be repeated a few times in a ToC and we could also have fragments. Creating a spine out of a ToC means extra processing rules, whereas using the text nodes of a spine is super easy.