Binder Document Specification, Version 1.0

1.4.1 Imperative Level

The requirement level imperatives described in Section 1.3 are highlighted based on three basic imperative levels: required, recommended, and optional.

1.4.2 Elements, Attributes and Attribute Values

The normative XHTML 1.1 edition of this specification includes special markup for every mention of elements, attributes, attribute values, and other related code. (For details, refer to the comment in the source document header.) This allows these markup constructs to be specially highlighted, using CSS, during presentation (including their status and requirement level) so they may be more easily recognized.

Since the normative edition of this specification may be rendered with different CSS style sheets, converted into other formats, rendered on visually limited hardware, or presented with text-to-speech engines, some or all of this highlighting may be lost. Care has been taken to assure that, in the absence of highlighting, every mention of these markup constructs will be clear and unambiguous.

In the above tables, there are four requirement levels:

1. “Required” means the element/attribute must appear, in some capacity, in all Binder documents.

2. “Conditionally Required” means the element/attribute must appear under certain element usage situations, and is optional in other situations.

3. “Optional” means the element/attribute is optional under all situations.

4. “Fixed” (applicable only to attributes) means the attribute is fixed to a certain value in the DTD and there is no separate requirement the attribute must appear in the associated element.

Similarly, there are three status levels:

1. “Normal” means the element/attribute has normal status in this specification.

2. “Deprecated” means the element/attribute has been deprecated, and support for it may be removed in a future version of this specification.

3. “Removed” means the element/attribute is no longer supported in this specification, but is nevertheless mentioned.

An empty cell in the tables means there is no mention in this specification of an element/attribute having the associated status and requirement level.

Attribute values are highlighted as en-US.

Other types of “code” are highlighted as PCDATA.

3.3.1 Important XML Markup Requirements

As specified in Section 3.1, all Binder Documents must be conforming XML 1.0 documents, which means, for example, they are well-formed. Following is a list of several specific XML markup requirements, but this list is by no means exhaustive. These requirements are mentioned since, when not followed, they contribute to a large fraction of encountered XML well-formedness and validation errors.

• Element and attribute names are case-sensitive. For example <binder> and <BINDER> are different elements.

• Attribute values must be enclosed in either single or double straight quotes. For example, lang="en-US" and lang='en-US' are conforming, but lang=en-US, lang="en-US' and lang='en-US" are not.

• All non-empty elements must have properly formed starting and closing tags.

• All declared empty elements must be properly formed (see Section 3.3.5).

• All elements must properly nest.

• Depending upon the circumstance, certain markup characters, when used literally (e.g. & and <), must be escaped. Refer to the next Section 3.3.2 for details.

3.3.2 Character Entity and Numeric Character References

For XML 1.0 documents (and this includes Binder Documents), each individual character within character data is represented in one of two ways:

1. directly in the document’s text encoding, and

2. indirectly using a numeric character reference, or by a predefined or declared character entity reference which points to a numeric character reference.

For example, it is convenient to use numeric character references and allowed character entity references when the tool used to create an XML document is limited to ASCII encoding (UTF-8 conformant but limited to the Basic Latin script), and some characters fall outside of the ASCII range.

In certain circumstances, five of the characters used to define XML markup constructs (specifically & < > " and '), when used literally, must be represented (or “escaped”) by their numeric character references, or by their declared character entity reference equivalents. For this purpose, XML predefines entity references for these five characters which all XML processors must recognize:

Listed below are the circumstances when the five markup characters, used literally and not as part of markup, must be escaped:

1. The & and < characters, except when used within CDATA sections and Comments.

2. The " and ' characters when they appear within an attribute value and match the attribute value delimiting quote mark. It is recommended that both always be escaped in attribute values.

3. The > character in the very rare instance it appears in the string “]]>” when that string is not marking the end of a CDATA section. It is considered good practice to escape the > character wherever it is used literally.

Example of Binder Document markup with both required and optional numeric and character entity references:

<title comment='Jane&apos;s AT&amp;T R&#x00E9;sum&#x00E9;'>Jane's AT&amp;T R&#x00E9;sum&#x00E9;</title>

A user agent will render the above content as:

Jane's AT&T Résumé

3.3.3 CDATA Sections

CDATA sections may be used in XML documents (which includes Binder Documents) to escape blocks of text containing markup characters (e.g. “<” and “&”) when used literally. This is an alternative to individually escaping each markup character (see Section 3.3.2).

A CDATA section starts with “<![CDATA[” and terminates with “]]>”.

CDATA sections may be used anywhere character data may occur, except that they must not appear within an attribute value. They must not nest; the text content within a CDATA section must not contain the literal character sequence “]]>”.

Example:

<xhtml:span>Insert the following: &lt;h1&gt;Greetings!&lt;/h1&gt;</xhtml:span>

is equivalent to

<xhtml:span>Insert the following: <![CDATA[<h1>Greetings!</h1>]]></xhtml:span>

A user agent will render both of the above as:

Insert the following: <h1>Greetings!</h1>

3.3.4 Comments

Comments may appear anywhere in an XML document (including a Binder Document) except before the XML declaration and within other markup. Comments are not part of the character data; they are primarily intended for Binder Document authors to insert private commentary (notes) within the document.

A comment starts with “<!--” and terminates with “-->”; the comment text is between these two delimiters. The comment text must not contain the string “--” (two hyphens), but otherwise may include, without escaping, all the Unicode characters recognized in XML 1.0, including the XML markup characters. A comment must not terminate with the literal string “--->”.

Examples of valid comments:

<!-- This is a comment -->

<!-- & < > " ' -->

To conform to this specification, user agents must not:

1. render the contents of comments,
2. execute any script or code (such as JavaScript) contained in comments,
3. take any action based on the content in comments.

3.3.5 Empty Elements and Empty Content

Some elements in a DTD may be declared EMPTY. When used in an XML document, these elements must not contain any content and must use the empty-element syntax (also known as “minimized form”) as specified in XML 1.0.

Example of correct usage of declared empty element syntax (the element item is declared EMPTY in this specification):

<item resid="css1" resource="style1.css" media-type="text/css"/>

Note: a sequence of one or more white space characters may appear before the closing “/” in empty-element syntax.

In this specification, the empty-element syntax must only be used for declared empty elements; it must not be used for declared non-empty elements when they contain no content.

Example of correct and incorrect usage when a declared non-empty element contains no content (the element dc:title is declared non-empty in this specification):

<dc:title/>             <!-- not allowed! -->
<dc:title></dc:title>   <!-- correct usage -->

When declared non-empty elements contain no content, or only a sequence of one or more white space characters, this occurrence is referred to as “empty content.”

3.3.6 White Space Handling

White space characters and their handling by user agents is an important consideration to both Binder Document authors and user agent developers.

In XML, the white space characters are:

• space ( )

• tab (	)

• carriage return (
)

• line feed (
)

The rules for white space handling of both character data and attribute values by XML processors are addressed in Sections 2.10, 3.2.1 and 3.3.3 of the XML 1.0 Specification.

User agent requirements:

1. For character data, XML processors are required to pass to the user agent all characters in a document that are not markup. This includes white space characters.

   Except where the XML attribute xml:space is specifically set to the value of preserve, or a similar override mechanism is applied (e.g., the CSS white-space property), in this specification user agents must normalize the character data of an element as follows:

   • Replace all sequences of two or more white space characters with a single space character ( ), and

   • Remove all leading and trailing spaces.

   Example:

   <dc:title>
      <xhtml:em> This
      </xhtml:em>    is a
              Title
   </dc:title>
   

   and

   <dc:title> <xhtml:em> This    </xhtml:em>   is   a Title </dc:title>
   

   are both equivalent to:

   <dc:title><xhtml:em>This</xhtml:em> is a Title</dc:title>
   

2. For white space in attribute values, XML requires that all XML processors normalize attribute values before sending the attribute value data to the user agent. Note that this normalization process treats attribute values not of type CDATA differently from those of type CDATA.

   To conform to this specification, user agents must normalize CDATA attribute values as if they were not of type CDATA. That is, for attribute values of type CDATA, user agents must replace a sequence of space ( ) characters with a single space ( ) character, and remove any leading and trailing space ( ) characters.

   Example (the comment attribute is of datatype CDATA):

   <style cssrefs="css1" comment=" This is   a
   
       style sheet "/>
   

   is equivalent to:

   <style cssrefs="css1" comment="This is a style sheet"/>
   

3.3.7 Unicode Space Characters and Related Topics

Binder Document authors are free to use all the Unicode characters in character data, except those disallowed by XML and this specification (refer to "Unicode in XML and other Markup Languages" for recommendations on the Unicode characters not suitable for use in XML, and related topics.) This flexibility allows for the richest content in Binder Documents, meeting nearly all international needs, but in certain situations will create a few complexities for Binder Document authors and user agent developers.

One of the more complex topics concerns the spacing characters used for inter-word separation. Because the concept of a “word” in most languages plays a fundamental role in various word-related operations, such as text searching, line breaking, etc., Binder Document authors and user agent developers need to understand how the Unicode space characters are used to enable inter-word separation, plus the related topics of line breaking (primarily for the purpose of visual presentation), and soft hyphens.

<dc:title>How to Insert a Soft Hy&shy;phen Within a Word</dc:title>

How To Insert a Soft
Hyphen Within a Word

How To Insert a Soft Hy-
phen Within a Word

4.2.1 The Common Attribute Set

The Binder Document vocabulary defines three [Common] attributes that may be applied to most elements. They are xml:lang, xml:id, and comment.

4.2.2 lang Attribute

The lang attribute may be applied to the required resources, item, and userset elements. Its purpose is to specify Publication-related languages.

The lang attribute differs from the xml:lang attribute (see Section 4.2.1.1) in that xml:lang is intended only to specify the language of element character data and attribute values within a Binder Document.

lang also differs from xml:lang in that lang may contain multiple language assignments which are separated by one or more white space characters. Each assigned language follows the rules given for xml:lang in Section 4.2.1.1.

Example:

lang="en-US de-DE"

It is possible for both xml:lang and lang to appear in the same element, and their assigned language values may differ.

Example:

<item resid="image1"
      resource="image1.png"
      media-type="image/png"
      lang="fr-FR"
      xml:lang="en-US"
      comment="Photograph of Paris (caption in French)"/>

In the above example, xml:lang is assigned the value en-US since the value of the comment attribute is in English. The lang attribute is assigned the value fr-FR since the Publication resource, image1.png, is a photograph with a caption in French.

4.2.3 residrefs Attribute

The required attribute residrefs is applied to several elements to reference one or more resource identifiers assigned in the Resource Manifest (see Section 4.4.3.) It is of datatype IDREFS, and must be a white space separated list of resource identifiers.

(XML 1.0 discussion of datatype IDREFS.)

4.2.4 title Element

The required title element is used in the Publication Title, Styling, and Navigation functional parts of the User Set.

Each title element contains character data (#PCDATA) representing a title description, and may also contain the XHTML Namespace Inline Elements (see Section 4.2.5).

Example:

<title>Title of <xhtml:em>This</xhtml:em> Book</title>

4.2.5 XHTML Namespace Inline Elements

All of the elements in the Binder Document vocabulary which may contain character data (#PCDATA), with the exception of the id element, may also contain inline elements drawn from the XHTML Namespace.

The nine supported inline elements allow Binder Document authors to add semantic richness to the character data. When these inline elements are used in character data, user agents should apply appropriate styling when presenting the character data.

As in XHTML, the inline elements may be nested. The Binder Document Common Attributes may be applied to these elements, as well as the optional class attribute which is drawn from XHTML. (Description) This specification does not specify how user agents are to use the value of the class attribute when present. However, a future version of this specification may add support for author-supplied CSS for styling the XHTML Inline elements, and the class attribute will be useful for CSS styling purposes.

The following table lists the supported XHTML Namespace Inline elements. Each supported element is linked to the general description in the HTML 4.01 specification, providing a good overview of the purpose and use of the element.

Example of the use of XHTML Namespace Inline elements:

<pubtitle>
   <title>Title of <xhtml:em>This</xhtml:em> Book</title>
</pubtitle>

A user agent may visually present the above character data as:

Title of This Book

4.2.6 “Mnemonic” Character Entity References

The Binder Document DTD declares the 253 character entity references specified in the Character Entity References Common Set Specification, Version 1.0. These character entity references are identical to those supported in XHTML 1.1 (which, in turn, are inherited from HTML 4.01.) They include the five XML predefined character entity references (see Section 3.3.2.)

Binder Document authors may use these “mnemonic” character entities instead of the equivalent numeric character references, as explained in Section 3.3.2. User agents must recognize these character entities.

Example using numeric character references:

<title>Jane&#x2019;s AT&#x0026;T R&#x00E9;sum&#x00E9;</title>

The same example using “mnemonic” character entity references:

<title>Jane&rsquo;s AT&amp;T R&eacute;sum&eacute;</title>

Both the above examples will render as:

Jane’s AT&T Résumé

Future versions of this and related Binder Document specifications may support an expanded common set of “mnemonic” character entity references derived from other document markup vocabularies such as TEI and DocBook.

4.3.1 Character Restrictions

Since the primary Publication Identifier may be used with Internationalized Resource Identifiers (RFC 3987) as part of an absolute path segment, the characters used should be restricted, whenever possible, to the ipchar production of RFC 3987 (page 7). (This is not always possible with certain formalized identifier namespaces. An example is the Digital Object Identifier namespace, DOI, which includes the “/” character in its identifier — the “/” character is not included in the ipchar production.)

When the Binder Document author devises their own unique primary identifier namespace, it is recommended that their namespace restricts the allowed primary identifier characters to some subset of the iunreserved production of RFC 3987 (page 7).

The primary identifier must not contain any white space characters. Also, the primary identifier must not contain any percent encodings except when the primary identifier namespace requires it. (Note that applications which extract the primary identifier from a Binder Document and embed it into an IRI or URI may convert certain characters, as necessary, to their percent encoded equivalents.)

4.3.2 type Attribute

The required type Attribute for the id element must be given the value of primary.

This requirement is for future compatibility when the Publication Identifier functional part is expanded to include alternate, antecedent, and other types of Publication identifiers.

4.3.3 idns Attribute

The required idns attribute for the id element specifies the scheme and namespace associated with the primary identifier. It must take one of the following forms:

1. Uniform Resource Name (URN) Scheme

   The current list of registered URN Scheme Namespaces is maintained by IANA, and governed by RFC 3406.

   The syntax for the value of idns, following RFC 2141, is given as

   <IDNS> ::= "urn:" <NID>
   

   Where “urn:” is the scheme, and <NID> is one of the formally registered URN Namespaces. Note that the leading “urn:” and the Namespace Identifier <NID> are case-insensitive per RFC 2141 — however, for consistency, Binder Document authors must use all lower case.

   Not all of the registered URN Scheme Namespaces are suitable for use as a primary identifier. At least two of them, ISBN and UUID, are suitable, and these two are the most likely to be used of those currently registered.

   Example use of the URN Scheme with a UUID Namespace for the idns attribute value:

   idns="urn:uuid"
   

2. “info” Scheme

   The “info” URI Scheme, managed by OCLC, currently supports a number of identifier namespaces that may be usable for Publication Identifiers. Notably, these include Digital Object Identifiers (“doi”), Fedora Digital Objects and Disseminations (“fedora”), and Serial Item and Contribution Identifiers (“sici”).

   The syntax for the value of idns is given as

   <IDNS> ::= "info:" <NID>
   

   Where “info:” is the scheme, and <NID> is one of the formally registered “info” Namespaces. Note that the leading “info:” and the Namespace Identifier <NID> are case-insensitive — however, for consistency, Binder Document authors must use all lower case. The trailing “/” character, specified by the “info” URI Scheme, must not be included in the idns attribute value.

   Example use of the “info” Scheme with a DOI Namespace for the idns attribute value:

   idns="info:doi"
   

3. “x-other:” Scheme

   The “x-other:” Scheme is intended for unregistered, private identifier namespaces, such as one designed by the Binder Document author. The syntax essentially follows that of the formal schemes already described (see example below.)

   It is strongly recommended that instead of using the “x-other:” Scheme, Binder Document authors should generate a globally unique Publication Identifier using the freely usable UUID Namespace with the URN Scheme. There are a number of free UUID generators, as well as UUID registration services.

   Example use of the “x-other:” Scheme for the idns attribute:

   idns="x-other:my-own-pubid-namespace"
   

4.3.4 ver Attribute

The required ver attribute for the id element provides for versioning of a given Publication Identifier. Its value is an integer, and for its first use with a particular Publication Identifier must be assigned the value of “1”.

When small or minor changes are made to any of the resources of a Publication, but not enough to warrant a change in Publication Identifier, the publisher should increment the version number by one.

Changes which qualify as small or minor include any edits that break few, if any, already-established links into the Publication based on resource and element IDs. However, if the Publication is significantly edited, such as substantive changes to its markup structure or major content revisions, then the publisher should consider assigning a new Publication Identifier (with a reset of ver back to “1”.)

4.3.5 Markup Example

Example markup of the Publication Identifier:

<pubid>
   <id type="primary"
       idns="urn:uuid"
       ver="1">6a2014b0-87a2-11da-a72b-0800200c9a66</id>
</pubid>

4.4.1 resource Attribute

The required resource attribute for the item element gives the path and name for a Publication resource. The overarching publication framework, which references this Binder Document specification, defines the resource path/filename scheme, and allowed characters.

Example:

resource="documents/chapter1.xml"

4.4.2 media-type Attribute

The required media-type attribute for the item element gives the MIME media type of the resource.

Example:

media-type="application/x-orp-bcd1+xml"

4.4.3 resid Attribute

The required resid attribute for the item element assigns a resource identifier for the resource. As noted in Section 4.4.5, a resource may be assigned multiple resource identifiers by applying multiple instances of the item element to that resource.

The datatype of the resid attribute value is ID, and the allowed characters are the same as those specified for xml:id (see Section 4.2.1.2). Each resid must be unique across all ID values in the Binder Document.

Example:

resid="chap1"

Two important benefits of assigning resource identifiers to resources are:

1. Provides greater flexibility to the publishing work flow by allowing resource paths and names to change without disrupting the Publication organization, and

2. Preserves the integrity of both inter-document links and external links into Publications, provided the link addressing is enabled with resource identifiers rather than resource names.

4.4.4 lang Attribute

The optional but recommended lang attribute may be applied to both the resources and item elements. Section 4.2.2 provides an overview of the general purpose and requirements of this attribute.

The specific purpose for the lang attribute in the Resource Manifest is to assign the primary and/or significant language(s) to resources. Since this attribute may contain more than one language assignment, lang may assign multiple languages to a single resource. In this instance, the order of the languages in lang is significant, from highest to lowest priority or significance, but otherwise this specification does not distinguish the relative significance between the multiple languages.

For example, a content document may contain portions of text whose languages differ from the primary language. In this case, the primary language is listed first in the attribute value, followed by the other languages.

When lang is applied to the resources element, it globally applies to all resources in the Resource Manifest except where overridden for particular resources by applying the lang attribute to the associated item elements. The lang attribute may be applied to an item element even when lang is not applied to the resources element.

Although assigning languages to resources in the Resources Manifest is optional, Binder Document authors should do so. A future version of this specification may elevate this recommendation to a requirement.

Example of assigning languages to resources:

<resources lang="en-US">
   <item resid="chap1"
         resource="chapter1.xml"
         media-type="application/x-orp-bcd1+xml"
         lang="en-US de-DE"/>
   <item resid="chap2"
         resource="chapter2.xml"
         media-type="application/x-orp-bcd1+xml"
         lang="fr-FR"/>
   <item resid="chap3"
         resource="chapter3.xml"
         media-type="application/x-orp-bcd1+xml"/>
   ...
</resources>

In the above example, all the resources in the Resource Manifest are globally assigned English (US). For the content document resource with resource identifier “chap1”, the global language has been overridden, with a primary language of English, but with some text in German. For the content document resource “chap2”, the global language has been overridden with the primary language of French. For the content document resource “chap3”, since the lang attribute does not appear, its primary language is the globally assigned language, English.

4.4.5 Assigning Multiple Resource Identifiers To a Resource

As noted in Section 4.4.3, a resource may be assigned multiple resource identifiers by using multiple item elements.

This is a powerful feature which allows Publication authors to efficiently reuse resources when they appear in different contexts in their Publications.

For example, the same content document may appear in various portions of the Publication, and each appearance may use a different set of style sheets.

This mechanism may simplify some publishing work flows where having multiple copies of the same resource, each given a different resource (or file) name, adds an unnecessary complication, particularly in the document editing process.

This mechanism also makes it feasible for unambiguously linking to the correct spot within a Publication when a resource is used multiple times, provided the link addresses the resource identifier and not the resource name.

Example of applying two resource identifiers to one resource:

<item resid="intr1"
      resource="document/intro.xml"
      media-type="application/x-orp-bcd1+xml"
<item resid="intr2"
      resource="document/intro.xml"
      media-type="application/x-orp-bcd1+xml"/>

In the example above, the content document resource “intro.xml” is assigned two resource identifiers: intr1 and intr2.

4.4.6 Markup Example

A fairly complex and lengthy markup example of the Resource Manifest:

<resources lang="en-US">
   <item resid="intr1"
         resource="intro.xml"
         media-type="application/x-orp-bcd1+xml"
         comment="Special introduction written by Jane Doe"/>
   <item resid="intr2"
         resource="intro.xml"
         media-type="application/x-orp-bcd1+xml"/>
   <item resid="chap1"
         resource="chapter1.xml"
         media-type="application/x-orp-bcd1+xml"/>
   <item resid="chap2"
         resource="chapter2.xml"
         media-type="application/x-orp-bcd1+xml"/>
   <item resid="note1"
         resource="note1.xml"
         media-type="application/x-orp-bcd1+xml"/>
   <item resid="note2"
         resource="note2.xml"
         media-type="application/x-orp-bcd1+xml"/>
   <item resid="css-a"
         resource="cssdir/a.css"
         media-type="text/css"/>
   <item resid="css-b"
         resource="cssdir/b.css"
         media-type="text/css"/>
   <item resid="css-c"
         resource="cssdir/c.css"
         media-type="text/css"/>
   <item resid="css-d"
         resource="cssdir/d.css"
         media-type="text/css"/>
   <item resid="css-e"
         resource="cssdir/e.css"
         media-type="text/css"/>
   <item resid="imag1"
         resource="images/image1.png"
         media-type="image/png"
         lang="fr-FR"
         xml:lang="fr-FR"
         comment="La Tour Eiffel"/>
   <item resid="imag2-jpeg"
         resource="images/image2.jpg"
         media-type="image/jpeg"/>
   <item resid="imag2-png"
         resource="images/image2.png"
         media-type="image/png"/>
   <item resid="imag2-tiff"
         resource="images/image2.tiff"
         media-type="image/tiff"/>
   <item resid="imag3"
         resource="images/image2-thumb.png"
         media-type="image/png"/>
   <item resid="tabl1"
         resource="images/table1.png"
         media-type="image/png"/>
</resources>

4.5.1 General Usage of the Dublin Core Metadata Element Set

The fifteen Dublin Core metadata elements share the same content model. Each Dublin Core element may contain character data (#PCDATA) representing the metadata information, and may also contain the XHTML Namespace Inline Elements (see Section 4.2.5) for enhancing user agent presentation of the metadata information — especially useful for metadata of a “prose” nature, such as that designated by dc:description and dc:title.

Several of the more important Dublin Core metadata elements, and those with specialized attributes, are described in greater detail in sibling sections; for information on the other elements, refer to the Dublin Core Metadata Element Set, Version 1.1 specification and related documents. The OEBPS 1.2 Specification, also discusses the use of the Dublin Core metadata elements (this specification adopts several of the OEBPS innovations in the use of Dublin Core metadata.) Binder Document authors should use the Dublin Core metadata elements consistent with Dublin Core recommendations, except where they conflict with the requirements of this specification.

The Binder Document already requires three critical metadata items which are designated elsewhere in the Binder: the Publication Identifier, the Publication Title (required for each User Set), and the Publication primary and secondary languages. Although redundant, Binder Document authors should replicate this information in the Dublin Core Metadata — the details are discussed in the relevant sibling sections.

Binder Document authors should specify the language, using xml:lang (see Section 4.2.1.1), for the “prose” containing metadata elements, such as dc:description and dc:title, when their language differs from the default language assigned to dublincore.

User agents should provide a mechanism allowing users, on demand, to access and review the Dublin Core metadata information.

4.5.2 dc:identifier

The dc:identifier element designates an identifier for the Publication. It should be included in the Dublin Core metadata. The first instance of use of this element in the Dublin Core metadata must replicate the primary identifier assigned in the Publication Identifier functional part.

The dc:identifier element supports two identifier-related attributes required by the id element in the Publication Identifier functional part: idns and ver.

The value of the required idns attribute, which specifies the identifier namespace, must follow the requirements in Section 4.3.3. Likewise, the value of the sometimes required (as noted below) ver attribute, which specifies the versioning of the identifier, must follow the requirements in Section 4.3.4.

In the first dc:identifier instance, which replicates the primary Publication Identifier, the idns and ver attributes must assume the values identical to their counterparts for the id element.

For the Publication Identifier markup example in Section 4.3.5, the dc:identifier equivalent is:

<dc:identifier idns="urn:uuid" ver="1">6a2014b0-87a2-11da-a72b-0800200c9a66</dc:identifier>

4.5.3 dc:title

The dc:title element designates the Publication title. It should replicate, whenever possible, the title given in the Publication Title functional part of the User Set.

A Publication title may comprise multiple lines, as the markup example in Section 4.7 illustrates. Each line in the Publication title will be expressed with its own dc:title element, and the order of appearance of dc:title elements is significant (they are not required to be adjacent to each other, although that is recommended for readability.) For the same primary language (as explained below), the dc:title elements form the complete Publication title by their order of appearance in the Dublin Core metadata.

A complication arises when there are multiple User Sets and the Publication title varies between them (which is allowed.) The title variation may be in the same primary language, or in two or more primary languages.

For multiple User Sets with variations of the Publication title, the Binder Document author should include in the Dublin Core metadata an appropriate Publication title (which may comprise one or more lines) for each primary language represented by the User Set titles. When there are multiple primary languages, the Binder Document author must apply the xml:lang attribute (designating the primary language) to all instances of dc:title in the Dublin Core metadata.

For the Publication Title markup example given in Section 4.7, the Dublin Core equivalent is:

<dc:title>Dr. Strangelove</dc:title>
...
<dc:title>Or: How I Learned to Stop Worrying and <xhtml:em>Love the Bomb</xhtml:em></dc:title>

In the above example, since both the dc:title elements are of the same language (inherited from a containing element where xml:lang is assigned US English), they form the two line Publication title:

Dr. Strangelove
Or: How I Learned to Stop Worrying and Love the Bomb

Note in the markup example above that even though appearance order is significant, the two dc:title elements need not be adjacent.

Markup example of dc:title with multiple lines and in multiple languages mixed together:

<dc:title xml:lang="en-US">A Trip To Paris:</dc:title>
...
<dc:title xml:lang="fr-FR">Un Voyage Vers Paris:</dc:title>
...
<dc:title xml:lang="en-US">Visiting The Eiffel Tower</dc:title>
...
<dc:title xml:lang="fr-FR">Visiter La Tour D'Eiffel</dc:title>

In the above markup example, the Dublin Core metadata designates two language-specific Publication titles (each comprising two lines.) The English version of the Publication title is:

A Trip To Paris:
Visiting The Eiffel Tower

The French version of the Publication title is:

Un Voyage Vers Paris:
Visiter La Tour D'Eiffel

4.5.4 dc:language

The dc:language element designates a significant language used in the Publication. For multiple Publication languages, use one instance of dc:language for each language. Binder Document authors should designate at least one primary language (see below) for the Publication.

Similar to the requirements for xml:lang (see Section 4.2.1.1), the character content of dc:language must comply with RFC 3066, or its successor on the IETF Standards Track. (Language Codes) (Country Codes)

The required attribute usage must be assigned either the value of primary or secondary, which indicates whether the language is considered a primary language of the Publication, or a secondary language. (Note that there may be more than one primary language of the Publication.)

The designated primary languages of the Publication should be all the unique languages specified in the required lang attribute for all instances of the userset element (see Section 4.6.3.)

The designated secondary languages of the Publication should be all the unique languages (other than those designated as primary), specified in the lang attribute for the resources and all the item elements (see Section 4.4.4), plus all the non-primary languages used in all the content documents of the Publication (usually designated in markup using xml:lang.)

Example:

<dc:language usage="primary">en-US</dc:language>
<dc:language usage="primary">fr-FR</dc:language>
<dc:language usage="secondary">de-DE</dc:language>

In the above example, two languages are designated as primary in the Publication: English and French — one reason for this might be that there are two User Set versions of the work associated with the Publication: one in English, and the other in French. One secondary language is designated: German — the reason might be that there is some German text in one of the content documents, or a particular video resource is spoken in German or has German subtitles.

4.5.5 dc:creator and dc:contributor

The elements dc:creator and dc:contributor are similar — both designate, in character data, the name of a person or entity responsible for some recognized role in the process to author the content of the Publication. Each element may be used any number of times as desired, such as to provide a sufficiently accurate accreditation of all those who played a recognized role in creating the Publication content.

Where the two elements differ is that dc:creator is to be used for those who played a primary or major role in the Publication content authoring/creation process (e.g., an author), while dc:contributor is to be used for those who played a secondary, supporting or minor role.

Because of the importance of authors/creators, Binder Document authors should include in the Binder all the creator metadata using dc:creator. User agents, when presenting the Publication to the user, should list the creators (and their roles, see below) along with the required Publication Title (refer to Section 4.7.)

For both elements, the required role attribute assigns the role (or roles) the person or entity played in the creation of the Publication content. This attribute is adopted from the OEBPS Specification with some modifications, and is an innovative extension to Dublin Core.

The value of the role attribute must be a white space separated list of one or more role values. Each role value must be either the three character code drawn from the extensive MARC Relator Codes List (and it must be all lower-case), or constructed in the form “oth.*”, where the string “*” is a role descriptor from another relator code list, or customized (this specification imposes no case or length restrictions for the “*” string, but the string must be of XML datatype NMTOKEN.) The “oth.*” form must not be used when there is an appropriate MARC Relator Code for the role.

The OEBPS Specification includes a convenient short list of the MARC Relator Code roles most likely to be used for Publication metadata. The most used MARC Relator Code is that for an author: aut.

In the situation where a creator or contributor was involved with some, but not all, of the User Sets in the Publication, the Binder Document author must include the usidrefs attribute which designates which User Sets the creator or contributor played a role. The usidrefs attribute value is a white space separated list of one or more User Set identifiers (see Section 4.6.1.) When the usidrefs attribute is not used, it is assumed that the creator or contributor played their assigned role(s) in all the User Sets of the Publication.

The optional but recommended file-as attribute, also adopted from OEBPS, may be used to specify a normalized form of the character data, suitable for machine processing, such as sorting by a person’s last name.

Example:

<dc:title>Markup Made Simple</dc:title>  <!-- The same title is designated for all User Sets -->
...
<dc:creator role="aut" file-as="Smith, John A.">John A. Smith</dc:creator>
<dc:creator role="ill" usidrefs="illus-version" file-as="Doe, Jane B.">Jane B. Doe</dc:creator>
<dc:contributor role="aui aft" file-as="Johnson, Adrian C.">Dr. Adrian C. Johnson</dc:contributor>
<dc:contributor role="oth.custom-font-design">Acme Font Company</dc:contributor>

Based on the requirements and recommendations of this specification, a user agent should present to the user the following “title page” information when presenting the User Set with identifier of illus-version (referring to the Illustrated Version of the Publication which Jane B. Doe played a creator role as illustrator):

Markup Made Simple
By John A. Smith
Illustrated by Jane B. Doe

However, if the user agent is presenting a different User Set of the Publication (such as the Non-Illustrated Version), the “title page” presented should not include Jane B. Doe since she did not play a creator role in that User Set:

Markup Made Simple
By John A. Smith

4.5.6 dc:date

The dc:date element designates the date/time for an important event in the life-cycle of the Publication, such as the publishing date. There may be any number of dc:date elements to cover multiple events.

The character data expressing the date/time of the event must conform to the W3C Note Date and Time Formats. For example, a full date (with no time) must be of the form YYYY-MM-DD (e.g., “2006-05-29”).

The required attribute event, adopted from OEBPS, assigns a name to the event. The set of values for the event attribute are not defined in this specification. Possible values (suggested in the OEBPS Specification) may include: creation, publication, and modification.

Example:

<dc:date event="publication">2006-05-29</dc:date>

4.5.7 dc:subject

The dc:subject element, which may occur any number of times in the Binder metadata, designates the subject or topic keywords. The Dublin Core Metadata Element Set Specification states the following about dc:subject:

Typically, Subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.

For example, one formal standardized subject naming scheme that may be used is the Library of Congress Subject Headings.

The optional scheme attribute may be used to designate the scheme associated with the character data value of dc:subject.

This specification does not endorse/recommend any particular subject naming scheme, nor sets any requirements for the scheme attribute value. However, a future version of this specification may give more guidance and set recommendations on both subject naming schemes and the scheme attribute value.

Example:

<dc:title>My Ántonia</dc:title>
<dc:creator role="aut" file-as="Cather, Willa Sibert">Willa Cather</dc:creator>
<dc:creator role="ill" file-as="Benda, Wladyslaw Theodor">W. T. Benda</dc:creator>
...
<dc:subject scheme="lcsh">Women immigrants--Fiction.</dc:subject>
<dc:subject scheme="lcsh">Farmers’ spouses--Fiction.</dc:subject>
<dc:subject scheme="lcsh">Czech Americans--Fiction.</dc:subject>
<dc:subject scheme="lcsh">Women pioneers--Fiction.</dc:subject>
<dc:subject scheme="lcsh">Married women--Fiction.</dc:subject>
<dc:subject scheme="lcsh">Friendship--Fiction.</dc:subject>
<dc:subject scheme="lcsh">Farm life--Fiction.</dc:subject>
<dc:subject scheme="lcsh">Nebraska--Fiction.</dc:subject>

In the above example, the Library of Congress Subject Headings were taken from a particular Library of Congress catalog entry for a 1986 edition of the book My Ántonia, by Willa Cather, illustrated by W. T. Benda. The scheme is designated as lcsh, a value not standardized in this specification. Since there are multiple subject headings associated with this book, each subject heading is represented by its own dc:subject element.

4.6.1 usid Attribute

The required usid attribute for the userset element assigns an identifier to the User Set.

The datatype of the usid attribute value is ID, and the allowed characters are the same as those specified for xml:id (see Section 4.2.1.2). Each usid must be unique across all ID values in the Binder Document.

The User Set identifier enables addressing of a particular User Set within a Publication. The overarching framework which references the Binder Document specification defines the addressing scheme, and whether or not a link in one User Set may reference content in another User Set in the same Publication.

Examples:

usid="1"
usid="userset1"
usid="scholarly-version"

4.6.2 mode Attribute

The required mode attribute for the userset element must be assigned the value “oeb” or “web”.

Refer to Section 4.6.5 for a detailed explanation of the mode attribute.

Examples:

mode="oeb"
mode="web"

4.6.3 lang Attribute

The required lang attribute for the userset element assigns the primary language(s) of the User Set. Section 4.2.2 provides an overview of the general purpose and requirements of this attribute.

Since this attribute may contain more than one language assignment, the order of the primary languages in lang is significant, from highest to lowest priority or significance, but otherwise this specification does not distinguish the relative significance between the multiple primary languages.

Example:

lang="fr-FR de-DE"

In the example above, two languages, French and German, are listed as primary languages of the User Set. The first declared language, French, is considered to have higher, if not equal, significance — the relative significance between the two languages is not defined in this specification.

4.6.4 title Attribute

The title attribute for the userset element provides a descriptive title for the User Set. While it is optional when there is only one User Set in a Binder Document, it is required (on all User Sets) when there are two or more User Sets in a Binder Document.

The attribute value of title is datatype text (CDATA), with the allowed Unicode character range the same as that for the comment attribute value (see Section 4.2.1.3.)

Note that the value of the title attribute is descriptive of the User Set itself. It is not the same as the Publication Title, which designates the title of the Publication specific to the User Set. Refer to the markup example of Section 4.6.6.

4.6.5 oeb and web Modes

The Mode setting (mode attribute, see Section 4.6.2) is an innovative feature not implemented in prior generation XML-based publication frameworks, such as OEBPS. Mode essentially instructs user agents how to treat the general presentation of the User Set.

In “oeb” mode, the user agent should present the User Set consistent with the classic OEBPS paradigm, where the Spine (see Section 4.9) expresses the primary or main part of the content. There may be out-of-spine content referenced from the Spine and the Navigation Set(s) (in turn, out-of-spine content may reference other out-of-spine content as well as reference back to any part of the Spine), but such content is considered in the OEBPS paradigm to be fairly minor in scope, typically auxiliary or amplificatory to the main Spine content.

The “oeb” mode is intended for Publication types which are essentially linear in construction. A classic example is traditional fiction where the content is highly linear and is intended to be read from start to finish.

In “web” mode, the user agent should present the User Set consistent with the classic web paradigm. Here the Spine is treated as the “home page,” or “entry page” into the Publication, and the referenced out-of-spine content documents are treated as separate “web pages.” Unlike the “oeb” mode, the referenced out-of-spine content documents (which in turn may reference other out-of-spine content documents, as well as any part of the Spine) are considered of equal (or even greater) importance to the home page (Spine).

The “web” mode is intended for Publication types which are essentially non-linear or composite in construction, where linear order is not important, or where forced linearization actually harms comprehension of the content. These include, as a partial list only, reference manuals, encyclopedias, dictionaries, modern hypertext literature, cookbooks, newspapers, and periodicals. And “web” mode is appropriate when the Publication type is a web site whose pages and associated resources have been conformed to the requirements of the publication framework which references this specification.

This specification does not provide mode selection requirements or guidelines (other than the general description given above), leaving it to the Publication author to select the mode appropriate for their Publication. This specification also does not mandate how user agents are to present User Sets in each of the two modes. However, it is strongly recommended that user agents differentiate the presentation to the user based on mode.

[Informative Commentary] To further illustrate the differences between oeb and web modes, consider how a visual user agent might present publications in both modes. In oeb mode, the user agent presents the Spine in a main window in book-like fashion (e.g., as discrete, turnable pages.) Out-of-spine content, when actuated by the user clicking on a link, appears in a smaller popup window in front of the Spine content. When the user has finished reading the popup window, they perform some action causing the popup window to disappear — they are returned to the main window which has remained untouched. In web mode, each link to a referenced content document displays the new content in the main window, as a new “page,” rather than in a popup window.

4.6.6 Markup Example

Example markup of multiple User Sets declaring different language versions as well as both presentation modes (“oeb” and “web”):

<userset usid="english1"
         mode="oeb"
         lang="en-US"
         title="Complete English Version">
     ...
</userset>
<userset usid="french2-web"
         mode="web"
         lang="fr-FR"
         xml:lang="fr-FR"
         title="Accomplissez La Version Française">
     ...
</userset>

4.8.1 char Attribute for the range and point Elements

The required char attribute for the range and point elements assigns a white space separated list of one or more Unicode character code points.

Each Unicode character code point must be represented using the Unicode code point notational convention:

“…an individual Unicode code point can be expressed as U+n, where n is four to six hexadecimal digits, using the digits 0–9 and uppercase letters A–F (for 10 through 15, respectively). There should be no leading zeros, unless the code point would have fewer than four hexadecimal digits — for example, U+0001, U+0012, U+0123, U+1234, U+12345, U+102345.”

For the specific rules governing the use of the char attribute for the range and point elements, refer to Sections 4.8.4 and 4.8.5, respectively.

Example:

char="U+00A9 U+201C"

In the example above, two Unicode characters are listed: U+00A9 (the copyright sign) and U+201C (left double quotation mark.) The meaning of this attribute value depends upon which element it is applied.

4.8.2 render Attribute for the block, range and point Elements

The optional render attribute for the optional block, range and point elements specifies whether the assigned characters are important or not important (refer to the discussion in Section 4.8.)

The render attribute must be assigned either the value important or notimportant. The default value is notimportant when the render attribute is not applied.

Examples:

render="important"
render="notimportant"

4.8.3 block Element

When the User Set includes a large number of characters from a particular Unicode character block, the optional block element may be used to specify that block, using the required name attribute.

The value of the name attribute must be drawn from the list of block names in the Unicode Character Database. The case of the characters in the block name is not important; however, for consistency, the case should exactly follow that given in the Unicode Character Database.

Listing a block name rather than specifying particular code points (or a range of code points) does not imply that all the characters in the block are actually used in the User Set. However, this is usually not a problem in that glyph sets supported by user agents usually cover most, if not all, of the characters in specific Unicode character blocks. If a user agent has glyphs for nearly all the characters in a character block, it may assume it has complete coverage.

Example:

<characters>
   <block blockname="Basic Latin" render="important"/>
   <block blockname="Latin-1 Supplement" render="notimportant"/>>
   ...
</characters>

In the above example, the Character Manifest is stating that the content documents in the User Set include characters from the “Basic Latin” and “Latin-1 Supplement” blocks. Furthermore, the Publication author deems “Basic Latin” glyph support as important (refer to the discussion in Section 4.8), while glyph support for the “Latin-1 Supplement” is deemed not important.

4.8.4 range Element

The optional range element may be used to assign one or more ranges of Unicode characters that appear in the content documents of the User Set. This element may appear any number of times in the Character Manifest.

The character range or ranges are actually assigned using the required char attribute (for general information on this attribute refer to Section 4.8.1.)

For the char attribute as applied to the range element, the range or ranges of Unicode characters are specified using start/end pairs of white space separated Unicode character code points. If an odd number of code points are listed in the attribute value (including only one), then the last one must be ignored.

Publication authors should only list ranges where all the characters in each range actually appear in the content documents of the User Set. User agents must assume that when a range is listed, all the characters in that range appear in the content documents, except those code points which are not yet assigned in the Unicode specification.

Examples:

<characters>
   <range char="U+00C0 U+00FF U+2018 U+201F" render="important"/>
   <range char="U+0391 U+03A9 U+03B1"/>
   ...
</characters>

In the example above, for the first range element, two ranges of Unicode characters are specified: U+00C0 to U+00FF, and U+2018 to U+201F. In addition, the Publication author has declared both ranges to be important (refer to the discussion in Section 4.8.)

In the second range element, since there are an odd number of code points, the last one, U+03B1 is ignored, leaving one specified range of U+0391 to U+03A9. In addition, since the render attribute is not specified, the default value of notimportant is implied.

In both examples, user agents must assume that all the characters in all the listed ranges appear in the content documents of the User Set, except those code points not yet assigned in the Unicode specification. (For the second range element, the code point U+03A2 happens to be unassigned in Unicode.)

4.8.5 point Element

The optional point element may be used to assign one or more Unicode character code points appearing in the content documents of the User Set. This element may appear any number of times in the Character Manifest.

The character code points are actually assigned using the required char attribute (for general information on this attribute refer to Section 4.8.1.)

Publication authors should only list character code points which actually appear in the content documents of the User Set. User agents must assume that when a character code point is listed, it appears in the content documents, except when the code point is not yet assigned in the Unicode specification and added by mistake.

Examples:

<characters>
   <point char="U+2014 U+201C U+201D" render="important"/>
   <point char="U+00A9"/>
   ...
</characters>

In the first example, three Unicode characters are listed as appearing in the content documents of the User Set. The Publication author has declared all these characters as important (refer to the discussion in Section 4.8.)

In the second example, one Unicode character is listed as appearing in the content documents of the User Set. Since the render attribute is not specified, the default value of notimportant is implied.

4.8.6 Markup Example

Example markup of the Character Manifest:

<characters>
   <block blockname="Basic Latin" render="important"/>
   <block blockname="Latin-1 Supplement" render="notimportant"/>>
   <range char="U+0391 U+03A9 U+03B1 U+03C9" render="important"/>
   <point char="U+2014 U+201C U+201D" render="important"/>
   <point char="U+0192"/>
</characters>

In the example above, the elements within characters may appear in any order, and may be mixed.

4.16.1 Cascade Styling Principles

Cascade-type styling languages (such as CSS) are designed to “negotiate” content document styling between the intentions of the Publication author, and the needs and preferences of the user. This negotiation is done by a “cascading” prioritization process mediated by user agents. For CSS, the negotiation process is described in great detail in CSS 2.1, section 6.4.

The purpose of the Styling functional part (which itself enables cascading prioritization), is for Publication authors to conveniently and powerfully communicate their styling intentions to the user agent.

More specifically, for the Styling functional part, Publication authors may apply one or more cascade-type styling documents (“style sheets”) to a content document. When more than one style sheet is applied to a content document, the order of application is important, with the next style sheet having higher priority over the previous style sheet. This “cascading” of multiple style sheets results in a final set of styling instructions for the content document expressing the intention of the Publication author.

A style sheet may also be applied to multiple content documents which share a common markup structure. This is a powerful feature that simplifies styling and make it easier to edit, and swap, the styling for a User Set.

4.16.2 Structural Overview of the Styling Function

The Styling functional part is headed by the styling element, which may contain zero or more styleset elements, each of which represents a “Style Set” (see Section 4.16.3.)

Each styleset element must contain exactly one title element (which provides a descriptive title for the Style Set, see Section 4.2.4), followed by one or more style empty elements (see Section 4.16.4.)

4.16.3 styleset Element

Within the styling element, there may be any number of styleset elements, each of which represents a “Style Set.” The order of multiple Style Sets in styling is insignificant.

A Style Set provides a particular and complete styling of the User Set. The multiple Style Set capability allows Publication authors to provide different styling presentations for the User Set.

Each styleset element must contain exactly one title element (which should provide a unique, descriptive title for the Style Set, see Section 4.2.4), followed by one or more style empty elements (see Section 4.16.4.)

The styleset element must include two required attributes: media and priority.

The required media attribute is used to designate a “CSS media type” for the Style Set. The value of the media attribute must be one of the ten CSS media types listed in the CSS 2.1 Specification: all, braille, embossed, handheld, print, projection, screen, speech, tty, and tv.

The CSS media type of all is the “general default” in this specification and should be the CSS media type assigned by Publication authors for general-purpose Style Sets. The other CSS media type values should only be applied to Style Sets targeting specialized user agents.

The required priority attribute must be assigned either the value primary or alternate. For a given CSS media type, a user agent should apply, by default, the primary Style Set.

For all the Style Sets in a User Set:

1. There must be at least one Style Set with a CSS media type of all.

2. For each CSS media type appearing in the User Set, there must be one and only one Style Set designated as primary — the remaining Style Sets of that CSS media type must be designated as alternate.

Based on the above requirements, there must always be one Style Set in the User Set with a CSS media type of all and a priority of primary. For example, when there is only one Style Set in a User Set:

<styling>
   <styleset media="all" priority="primary">
      <title>Single Style Set</title>
      ...
   </styleset>
</styling>

When user agents encounter priority and/or CSS media type errors in the User Set, the following handling rules apply:

1. If two or more Style Sets of a given CSS media type are designated primary, user agents must designate the first Style Set among them as primary and the remainder are redesignated as alternate.

2. If all the Style Sets of a given CSS media type are designated alternate, then the first Style Set among them is redesignated as primary.

3. If a user agent supports a certain CSS media type (and this includes the general-purpose all CSS media type), but this CSS media type is not represented in the User Set, then the user agent must assume the Publication author did not supply a Style Set for that CSS media type — the user agent must not substitute another Style Set of a different CSS media type.

When there are multiple Style Sets of all the supported CSS media types in the User Set, the user agent, by some mechanism, must:

1. Inform the user of the existence of multiple supported Style Sets,

2. Provide a list on demand of all those supported Style Sets, which includes the descriptive titles assigned by the title elements and the values of the media attribute, and

3. Allow the user to manually select and apply the Style Set from the supported list.

4.16.4 style Element

Each Style Set must include one or more style empty elements which apply cascade-type styling document resources (hereafter referred to as “style sheets” following the CSS convention) to the content document resources used in the User Set.

Each style empty element must include the required attribute cssidrefs, and sometimes include the optional cdidrefs element. Both of these attributes are identical to residrefs (see Section 4.2.3), except that the resource identifiers they contain are restricted to particular resource media types: content documents for cdidrefs, and style sheets for cssidrefs.

Order is significant for the style sheets listed in cssidrefs — the order designates the “cascading” sequence of the style sheets. Order is not significant for the content document resources listed in cdidrefs.

For each style element, the cascaded style sheet resources listed in cssidrefs are applied to the content document resources listed in cdidrefs, if that attribute is present.

If the cdidrefs attribute is not present in style, then the cascaded style sheet resources listed in cssidrefs are applied to all of the content document resources in the User Set.

In addition, order is important for multiple style elements, where a particular content document may appear in multiple style elements in a Style Set. This, combined with style sheet cascading within the cssidrefs attribute value, allows for quite complex, yet easy to construct, style sheet assignments, as the example in Section 4.16.5 illustrates.

4.16.5 Markup Example

<styling>
   <styleset media="all" priority="primary">
      <title>Acmee Publishing Contemporary Style</title>
      <style cdidrefs="intr1 chap1 chap2 chap3" cssidrefs="css-a css-b"/>
      <style cdidrefs="intr1 note1 note2" cssidrefs="css-c css-d"/>
      <style cdidrefs="note2" cssidrefs="css-e"/>
   </styleset>
   <styleset media="all" priority="alternate">
      <title>Acmee Publishing 1920's Throwback Style</title>
      <style cssidrefs="css-f"/>
      <style cdidrefs="intr2" cssidrefs="css-g"/>
   </styleset>
   <styleset media="handheld" priority="primary">
      <title>Styling For Handheld Devices</title>
      <style cssidrefs="css-h"/>
   </styleset>
</styling>

In the above example, a Publication author has provided three Style Sets for the User Set. The CSS media type for two of them are designated all, and the third is designated handheld. The first Style Set is designated the primary one for the all CSS media type.

The application of the style sheets to the content documents is best illustrated by looking at particular content documents.

For example, in the first Style Set, for the content document with resource identifier intr1 (e.g., an introduction to the book), the style sheets (identified by their resource identifiers) are applied cascade-fashion in the following order of ascending priority: css-a, css-b, css-c, and css-d (notice that intr1 appears twice in the Style Set.) In the same Style Set, for the content document note2, the style sheets are applied in this order: css-c, css-d, and css-e (notice that note2 also appears twice in the Style Set.)

In the second Style Set, the style sheet css-f is applied to all the content documents in the User Set (since the cdidrefs attribute is not present in the first style element.) The style sheet css-g is then applied to the content document intr2. Thus, two style sheets are actually applied to intr2 in this order: css-f (assigned globally), and css-g (assigned explicitly.)

In the third Style Set, the single style sheet css-h is applied to all the content documents in the User Set. This is the simplest of the three Style Set assignments.

4.17.1 Structural Overview of the Navigation Function

The Navigation functional part is headed by the required navigation element which must contain one, and only one, primarynav element (designating the primary Navigation Set), and any number (including zero) of altnav elements (each designating a non-primary or alternative Navigation Set.) The altnav elements can be placed in any order before and after the primarynav element. Other than their different element names, both primarynav and altnav are identical to each other in their supported attributes and content models. In addition to the Common Attributes, the primarynav and altnav elements may include the optional tour attribute (See Section 4.17.2.)

The primarynav and altnav elements contain the following three elements in the given order: title (one required), desc (one optional), and pointer (one or more required). The required title element contains a brief, descriptive title for the Navigation Set, and the optional desc element provides a summary or abstract of the Navigation Set. Both these elements have content models as described in Section 4.2.4. The pointer element, which enables the pointer or link to the target (the “link target”), is described in Section 4.17.3.

4.17.2 tour Attribute for the primarynav and altnav Elements

The optional tour attribute for the primarynav and altnav elements allows the Publication author to request that the user agent provide “tour” functionality to the Navigation Set (see Section 4.17.4.)

When used, the tour attribute must be assigned one of two values: request and norequest. When the tour attribute is not present, it defaults to the value of norequest.

4.17.3 pointer Element

The required pointer non-empty element designates a particular link target in the Navigation Set. A Navigation Set must have at least one pointer element, and the order of multiple pointer elements is significant, designating the order of the link target items in the Navigation Set.

The pointer element contains the following three elements in the given order: label (one optional), title (one required), and desc (one optional).

The optional label element, used to designate a structural level “label” for the link target title, is further described in Section 4.17.3.1. The required title element contains a brief, descriptive title of the link target, and the optional desc element provides a summary or abstract of the link target. All three of these elements have content models as described in Section 4.2.4.

The link target of the pointer element is designated by the required elemrefs attribute. Refer to Section 4.17.3.2 for detailed information on the use of this attribute.

The hierarchical level of the link target associated with the pointer element is designated with the optional level attribute. Refer to Section 4.17.3.3 for detailed information on the use of this attribute.

The optional attribute targetclass may be applied to the pointer element to designate the link target class or type (i.e., “Chapter,” “Level 4 Section,” etc.) This specification does not recommend any particular system/scheme for the targetclass attribute value; Publication authors should use a consistent, uniform system. User agents may use the value of the targetclass, but are not required to do so. The datatype of targetclass is CDATA.

<pointer elemrefs="binder#sec4.17.3">
   <label><xhtml:strong>4.17.3</xhtml:strong></label>
   <title><xhtml:em>The Pointer Element</xhtml:em></title>
   <desc>This section describes how to use the Pointer element</desc>
</pointer>

       4.17.3 The Pointer Element

       4.17.3............The Pointer Element

<pointer elemrefs="chap1#para8"> ... </pointer>
<pointer elemrefs="chap1#para8 chap1#para10"> ... </pointer>
<pointer elemrefs="chap1#para8 chap3#para5"> ... </pointer>
<pointer elemrefs="orp-nullref"> ... </pointer>

<pointer elemrefs="chap1#para8"> ... </pointer>

<pointer elemrefs="chap1#para8"> ... </pointer>

<navigation>
   <primarynav>
      <title>Table of Contents</title>
      <pointer elemrefs="book#sec1" level="1"> ... </pointer>
      <pointer elemrefs="book#sec1.1" level="2"> ... </pointer>
      <pointer elemrefs="book#sec1.2" level="2"> ... </pointer>
      <pointer elemrefs="book#sec2" level="1"> ... </pointer>
      <pointer elemrefs="book#sec2.1" level="2"> ... </pointer>
      <pointer elemrefs="book#sec2.2" level="2"> ... </pointer>
      <pointer elemrefs="book#sec2.2.1" level="3"> ... </pointer>
      <pointer elemrefs="book#sec2.2.2" level="3"> ... </pointer>
      <pointer elemrefs="book#sec2.2.3" level="3"> ... </pointer>
      <pointer elemrefs="book#sec3" level="1"> ... </pointer>
   </primarynav>
</navigation>

4.17.4 Navigation: Further User Agent Requirements and Recommendations

With regards to navigation, when a user accesses a User Set in a Publication, user agents must:

1. Present to the user, on demand, all the Navigation Sets in the User Set. Each Navigation Set is to be identified to the user using the content of the required Navigation Set title element.

2. Identify which Navigation Set is primary.

3. Present to the user, on demand (if not by default), the link targets of each Navigation Set. Each link target is identified using the contents of the required link target title and the optional label elements (see Section 4.17.3.1.) Preserve and communicate the hierarchical level of the link targets when the Navigation Set is hierarchical (refer to Section 4.17.3.3.)

4. Allow the user to actuate any link in the Navigation Set and access the link target content, except when the user does not have the requisite access rights. (Access rights is outside the scope of this specification.)

In addition, user agents should:

1. Enable the “tour” feature for a Navigation Set when the tour attribute value is set to request (see Section 4.17.2.) The “tour” feature is similar to the OEBPS Tours, in that all the link targets in a Navigation Set can be visited in sequence with simple, “one button” actuation. (Note that User agents may enable the tours feature for all Navigation Sets.)

2. Allow users to access, by some means, the content in the desc element which may be applied at the Navigation Set and link target levels. The desc element provides a summary or abstract of the associated object that may be more descriptive and lengthy than the contents of the title element.

4.17.5 Markup Example

Following is example markup of the Navigation functional part, including two Navigation Sets, one of which is the required primary Navigation Set:

<navigation>
   <primarynav>
      <title>Table of Contents</title>
      <pointer elemrefs="book#sec1" level="1" targetclass="Level 1 Section">
         <label>1</label>
         <title>Introduction to Simplicity</title>
         <desc>
            This section provides an introductory overview about
            simplicity, and why you should care.
         </desc>
      </pointer>
      <pointer elemrefs="book#sec1.1" level="2" targetclass="Level 2 Section">
         <label>1.1</label>
         <title>Conventions Used In This Book</title>
         <desc>
            This section describes the conventions used in this book.
         </desc>
      </pointer>
      <pointer elemrefs="book#sec1.2" level="2" targetclass="Level 2 Section">
         <label>1.2</label>
         <title>References Consulted</title>
         <desc>
            This section discusses the various references on simplicity
            consulted by the authors of this book.
         </desc>
      </pointer>
      <pointer elemrefs="book#sec2" level="1" targetclass="Level 1 Section">
         <label>2</label>
         <title>Simplicity Made Simple</title>
         <desc>
            This section discusses how to make simplicity simple. It is
            not a simple thing to do!
         </desc>
      </pointer>
      <pointer elemrefs="book#sec2.1" level="2" targetclass="Level 2 Section">
         <label>2.1</label>
         <title>Simplicity Is Not So Simple</title>
         <desc>
            This section explains why simplicity is not simple at all!
         </desc>
      </pointer>
      <pointer elemrefs="book#sec2.2" level="2" targetclass="Level 2 Section">
         <label>2.2</label>
         <title>Three Steps To Make Simplicity Simple</title>
         <desc>
            There are three steps that you can do to realize that
            simplicity is simple. Once you realize this, then all
            will become simpler.
         </desc>
      </pointer>
      <pointer elemrefs="book#sec2.2.1" level="3" targetclass="Level 3 Section">
         <label>2.2.1</label>
         <title>Remember That Simple Is Simple</title>
         <desc>
            Remember that simple is simple! That is, simple is not
            complicated at all. Once you realize that, then everything
            gets a little bit simpler.
         </desc>
      </pointer>
      <pointer elemrefs="book#sec2.2.2" level="3" targetclass="Level 3 Section">
         <label>2.2.2</label>
         <title>Simple Is Also Good</title>
         <desc>
            Simple is good! Who believes that complicated is good?
         </desc>
      </pointer>
      <pointer elemrefs="book#sec2.2.3" level="3" targetclass="Level 3 Section">
         <label>2.2.3</label>
         <title>Simple Is Where It's At</title>
         <desc>
            Finally, realize that simple is cool while complicated is
            not. Who wants to be un-hip?
         </desc>
      </pointer>
      <pointer elemrefs="book#sec3" level="1" targetclass="Level 1 Section">
         <label>3</label>
         <title>Conclusion</title>
         <desc>
            In conclusion, simplicity is simple, and simple is good,
            therefore simplicity is good. Don't worry, be happy (and
            simple)!
         </desc>
      </pointer>
   </primarynav>
   <altnav tour="request">
      <title>List of Illustrations</title>
      <desc>
         This Navigation Set provides links to all the illustrations
         used in this Book about simplicity. The noted artist for
         these illustrations is John "Simple-Minded" Doe.
      </desc>
      <pointer elemrefs="book#illus1">
         <title>Illustration 1: Simple Is As Simple Does</title>
      </pointer>
      <pointer elemrefs="book#illus2">
         <title>Illustration 2: Simple Is Beautiful</title>
      </pointer>
      <pointer elemrefs="book#illus3">
         <title>Illustration 3: Simple Simon Met a Pieman</title>
      </pointer>
      <pointer elemrefs="book#illus4">
         <title>Illustration 4: We Are The Simple People</title>
      </pointer>
   </altnav>
</navigation>

A user agent might choose to visually present the primary Navigation Set of the above markup example (which is hierarchical in this example), something as follows. Note that the particular formatting used in the rendering below is example only — this specification does not recommend any particular visual (or other) presentation of Navigation Sets, allowing user agent developers to innovate in this area. Each link target item in the example below must include an active (or “null”, see Section 4.17.3.2) hypertext link to the link target. The user agent should provide some mechanism to allow the user to see the longer description/abstract for each link target; for example, mousing over a link target will bring up a popup window containing the longer description.

Table of Contents

1  Introduction to Simplicity
   1.1  Conventions Used In This Book
   1.2  References Consulted
2  Simplicity Made Simple
   2.1  Simplicity Is Not So Simple
   2.2  Three Steps To Make Simplicity Simple
        2.2.1  Remember That Simple Is Simple
        2.2.2  Simple Is Also Good
        2.2.3  Simple Is Where It's At
3  Conclusion

Likewise, the user agent might present the alternate, non-hierarchical Navigation Set in the markup example as follows. Note that the Binder Document author chose to keep the “Illustration n” portion of the link target titles within title and not move them to label elements, as the Binder Document author could have done.

List of Illustrations

Illustration 1: Simple Is As Simple Does
Illustration 2: Simple Is Beautiful
Illustration 3: Simple Simon Met a Pieman
Illustration 4: We Are The Simple People