View Full Version : Multiple reference elements with the same type in the <guide>


Valloric
04-25-2010, 08:40 AM
I've been brushing up on the <guide> element part of the OPF spec (http://www.idpf.org/2007/opf/OPF_2.0_final_spec.html#Section2.6)since I'm adding this functionality to Sigil, and from my understanding of it, it can have several <reference> elements with the same type.

That makes no sense to me.

How can a book have several Lists of Illustration, or several indices or several title pages? Sure, I could imagine an omnibus of sorts needing this, but it still seems... weird.

What I find particularly puzzling is that guide part of the spec IMHO seems to be written with the assumption that there can be no such duplicates. The description of the "text" type states:

First "real" page of content (e.g. "Chapter 1") So there can hardly be more than one of these, since the Reading Systems wouldn't be able to tell which of the multiples to show to the user as "the first real page of content". Also, other parts of the spec that allow duplication of semantics (like, say, multiple author metadata) have this possibility explicitly stated. There is no such statement for the guide <reference> elements.

Clearly, since the spec doesn't forbid it, it is allowed. What I'm interested in is whether this is a good idea. Honestly, I don't think it is.

And the least you could say about that part of the spec is that it should have a statement eliminating the ambiguity.

I'm interested in what others think about this.

Jellby
04-25-2010, 10:55 AM
In general, I agree, one would only want a single element of each type. But in other cases it would be too restrictive to have such a... er... restriction. A book can have several forewords, and definitely multiple (e.g.) other.map instances, each of them would be identified with a different "title" attribute. At the end of it, it's up to the reading system to properly handle these cases, and I'm sure all of them will assume there's only a toc and a cover (I don't even know a RS that deals with multiple titles or languages :rolleyes:), so even if it's allowed by the spec, and it could make sense in some cases, I don't think one should expect it to work any time soon...

Valloric
04-25-2010, 11:26 AM
A book can have several forewords

Even knowing that the spec allows using multiple guide references with the same type, I'd still put all those forewords into one XHTML and then list that with one reference element.

kovidgoyal
04-25-2010, 11:29 AM
As long as the combination of (type,title) is unique, I think its OK.

Valloric
04-25-2010, 11:38 AM
As long as the combination of (type,title) is unique, I think its OK.

Interesting point. But the "title" attribute is optional. What happens when there are several references with the same type, and no title?

The spec should resolve this ambiguity.

kovidgoyal
04-25-2010, 11:45 AM
Interesting point. But the "title" attribute is optional. What happens when there are several references with the same type, and no title?

The spec should resolve this ambiguity.

Certainly, the spec should specify that (title, type) must be unique. From the perspective of Sigil, I would assume that the spec does specify that.

Valloric
04-25-2010, 11:57 AM
Certainly, the spec should specify that (title, type) must be unique. From the perspective of Sigil, I would assume that the spec does specify that.

I'm not following you. The spec doesn't even mention the "title" attribute in the guide section (except in their small example, which is non-normative, so it in effect doesn't exist), and the only conclusive proof that it is indeed optional comes from the RELAX NG schema in Appendix A (http://www.idpf.org/2007/opf/OPF_2.0_final_spec.html#AppendixA):


<define name="OPF20.reference-element">
<element name="reference">
<ref name="OPF20.optional-id-attribute"/>
<attribute name="type">
<text/>
</attribute>
<optional>
<attribute name="title">
<text/>
</attribute>
</optional>
<attribute name="href">
<text/>
</attribute>
<ref name="OPF20.reference-content"/>
</element>
</define>

So I don't see how it can be assumed from the perspective of Sigil that the spec specifies that (title, type) is a unique tuple.

kovidgoyal
04-25-2010, 12:10 PM
I meant that if you impose that restriction, you will be compliant with the spec and not generate EPUB's with meaningless guide entries.

Valloric
04-25-2010, 12:18 PM
I meant that if you impose that restriction, you will be compliant with the spec and not generate EPUB's with meaningless guide entries.

Ah, that makes sense.

But I'm going to go with the Sigil UI only supporting one instance of one guide type per book. From what I gather, this is what 99% of the users want, and it also simplifies the UI (there's no need to input a separate title attribute).

Direct OPF editing will come in the future, so those 1% will be able to do that then.