2.2.1: Required Modules

OPS requires all conforming Reading Systems to support the following modules consistent with their descriptions in the XHTML and HTML specifications, unless otherwise specified in this document.

2.3.1: General Comments on URI References

A number of attributes reference resources using URI values (Uniform Resource Identifier, see RFC 2396, http://www.ietf.org/rfc/rfc2396.txt). Depending on the particular attribute, the URI referenced resource can either be an abstract entity or a physical object.

Except where noted or where not applicable, Reading Systems may use or render a URI referenced physical resource not listed in the Manifest (i.e., it is not a component of the Publication), but they are not required to do so.

2.3.2: body Element

It is assumed, in formatting, that the default rendering for body is consistent with the CSS property page-break-before having been set to right (which behaves like always on one-page Reading Systems), but may be overridden by an appropriate style sheet declaration.

2.3.3: cite Attribute

The optional attribute cite may be used in blockquote, q, del, and ins to provide a URI citation for the element contents. Reading Systems are not required to process or use the referenced URI resource, whether or not the resource is listed in the Manifest.

2.3.4: img Element

The inline element img should only be used to refer to images with OPS Core Media Types of GIF (http://www.w3.org/Graphics/GIF/spec-gif89a.txt), PNG (RFC 2083), JPG/JFIF (http://www.w3.org/Graphics/JPEG) or SVG (http://www.w3.org/TR/SVG11/). The required URI attribute, src, is used to reference the image resource, which must be listed in the Manifest.

The required alt attribute should contain a brief and informative textual description of the image. This text may be used by Reading Systems as an alternative to, or in addition to, displaying the image. The text is also an acceptable fallback for an img with src referencing a non-OPS Core Media Type for which no viable fallback was found in the manifest. The alt textual description is useful for Reading Systems having limited resolution displays, or for non-visual presentation. Use of the object element is the preferred mechanism for including non-core media types in an OPS Content Document.

For long descriptions, the optional title attribute may be used. Reading Systems may display the title attribute in addition to or in place of the alt text or displaying the image.

For greater accessibility, it is strongly recommended that OPS Content Document authors include a URI reference in the optional longdesc attribute referencing a resource (such as another OPS Content Document in the Publication) describing the image in finer detail. Reading System developers are also strongly urged to recognize and render in an appropriate fashion (and with accessibility in mind) the resource specified in longdesc. For further information on the use of this attribute and related accessibility attributes, see http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-provide-equivalents.

2.3.5: link Element

The link element allows for the specification of various relationships with other documents. Reading Systems must recognize external style sheet references specified via the href attribute and the associated rel attribute (for the values rel="stylesheet" and rel="alternate stylesheet".)

2.3.6: object and param Elements

The object element is the preferred method for generic object inclusion. When adding objects whose data media type is not drawn from the OPS Core Media Type list or which reference an object implementation using the classid attribute, the object element must specify fallback information for the object, such as another object, an img element, or descriptive text. Inline fallback information is provided as OPS content appearing immediately after the final param element that refers to the parent object. Descriptive text for the object, using inline content, an included OPS Content Document, or some other method, should be provided to allow access for people who are not able to access non-textual content.

The classid attribute of an object gives the URI value of an implementation for the object. Conformant Reading Systems are not required to render objects that use external implementations, although they may do so. The MIME media type values for the codetype and type attributes must match those specified in the Publication's Manifest.

The associated param empty element is used to specify initialization values for objects. The param element must only appear before the renderable content of an object. Reading Systems must examine only param elements that are direct children of the object.

Example:

<object classid="clsid:AFAFAFA-0101-1010-0101-ABABABABABA"
        codebase="http://www.example.com/SomeScriptingLanguage/">
   <param name="code" value="TicTacToe.class">
   <param name="codebase" value="html/">
   <param name="type" value="application/x-somescriptinglanguage">
   <param name="model" value="models/TicTacToe.model">
   <param name="scriptable" value="true">
   <object type="image/png" data="tictactoe.png">
           Tic-Tac-Toe, a <em>dull</em> game.
   </object>
</object>

2.3.7: script and noscript Elements

Reading Systems must not render the textual content of the script element, and should not execute the script itself. The content must be readable without execution of script elements.

If noscript is included, whose purpose is to display some message if the Reading System chooses not to execute the script, it must appear after the closing tag of the script it is associated with. Reading Systems must, by default, render the content contained in noscript if they do not execute script (as is recommended), the default of which can be overridden by CSS display:none. Note that for XHTML 1.1 conformance the content model for noscript is Block.mix (block level elements plus the "level-independent" elements); it cannot directly contain text or inline elements and is identical to the content model for body and blockquote, even if noscript itself appears inline.

The attribute type, which specifies the scripting language for script, is required.

One potential problem with script, whose content model is #PCDATA, is that if the code contains the characters "<" and "&", there is a potential conflict with XML. Thus, these characters, if used, must either be escaped, or put into a CDATA section. Reading System developers who include script execution capability need to be aware of this potential problem.

2.3.8: type attribute of the style element

The type attribute of the style element is required (per XHTML 1.1 requirements) and must be given the value of text/css or the deprecated text/x-oeb1-css. For browser rendering of an individual OPS Content Document as an XHTML 1.1 document, instances of the deprecated text/x-oeb1-css should be changed to text/css.

2.3.9: Value of align attribute

The value of char for the align attribute is not included in the OPS XHTML subset. To achieve similar formatting, use the CSS text-align property with a string value.

2.4.1: Introduction

DTBook is an XML vocabulary defined in the DAISY/NISO standard, formally, the ANSI/NISO Z39.86-2005 Standard. This vocabulary is specifically designed for eBook content. Many structures not found in XHTML are included: footnotes, sidebars, annotations, page numbers, etc. Identifying the beginning of pages and the number of the page in the original print publication enables direct NCX navigation to the beginning of each page as reflected in the print publication. These pages will vary in size from the screens of information displayed by a typical Reading System. The retention of print page marking will enable a user to move to the identical location as someone who may be using a printed book.

It is strongly recommended that Content Providers select this XML Preferred Vocabulary for their educational publications and for content that is highly structured.

Many publishers may already have their content in DTBook as a result of the U.S. Individuals with Disabilities Education Improvement Act (IDEIA) of 2004 or other similar international legislation. Transforming it into an OPS publication can be accomplished with ease. Having the publication available using the DTBook vocabulary may help publishers market their publications to all students in the education market place, including those with print disabilities.

Section 4 of the DAISY/NISO Standard defines the DTBook DTD. This can be found on the NISO Web site at: http://www.niso.org/standards/resources/Z39-86-2005.html.

Additional information such as DTDs, issues tracking, samples, and more can be found on the DAISY Web site at: http://www.daisy.org/z3986/.

2.4.2: DTBook Usage Requirements

DTBook, as described in Section 4 of the DAISY/NISO Standard, must be followed in DTBook OPS Publications. The content must validate against the dtbook-2005-2.dtd, which was the latest version at the time of this writing. This DTD version, all previous versions, and all future versions will be available on the DAISY website. This will ensure that OPS Publications created under any version of the DTD remain valid.

It is essential that the semantics of the DTBook elements be applied correctly. To assist with this, a set of "Structure Guidelines" has been created. Documents created conforming to DTBook should use the Structure Guidelines for information regarding the correct application of the semantics of the elements. The Structure Guidelines can be found at: http://www.daisy.org/z3986/structure/.

2.5.1: General Notes on SVG Usage

OPS supports the full SVG 1.1 Recommendation. The only exception is that since OPS is not targeting interactive content. SVG animation and scripting features are not supported and must not be used by publication authors; a Reading System should not render such content. CSS styling of SVG must be fully supported.

Text in SVG images should be selectable and searchable. SVG images may contain links (a elements) and thus may be used for navigation. If a Reading System supports "tabbing" through links, SVG links must be included.

Inline SVG is only supported within documents using the XHTML Preferred Vocabulary. It must not be used within DTBook documents.

2.5.2: SVG’s Use as a Standalone Image File

SVG content can be used in OPS in any place where other image types can be used. This includes:

• References from XHTML img and object elements
• References from DTBook img elements
• References from SVG image elements
• References from CSS properties that take an image URI as a parameter

To ensure maximum portability, the dimensions of SVG images should always be specified on the top-level SVG element . As with bitmap images, referencing elements may override an SVG image’s dimensions causing it to scale.

Each SVG image is considered a separate document for the purposes of styling. Referencing document style sheets do not apply to referenced SVG images, nor are CSS properties inherited by SVG images. Common styles should be achieved by creating style sheets that are referenced by both SVG and XHTML. Note that this is consistent with situations in which an object element references an XHTML element.

2.5.3: Mixing SVG and XHTML Mark-up in the Same Document

The other way of using SVG is to embed SVG mark-up directly in XHTML mark-up. The SVG root element (svg) must be considered replaced by its content in the CSS layout, so svg elements may be used anywhere XHTML img elements could be used. Other SVG elements may only be used as svg element descendants. Since SVG and XHTML elements have different namespaces, care needs to be taken to assign proper namespaces to each element using namespace prefixes or the xmlns attribute.

In this case, there is only one document and CSS style sheets apply to the document as a whole (including cascade and inheritance). In the usual manner, each element only makes use of the properties that are applicable to it. The root svg element’s role in CSS layout is determined by the display, float, and position properties, just like it works for the img element. SVG image dimensions are determined by the width and height attributes on the root svg element (which are considered to be the replaced element’s intrinsic dimensions in the CSS box layout) and the width and height properties assigned by CSS. See http://www.w3.org/TR/CSS2/conform.html for a definition of "replaced element" and "intrinsic dimensions." For portability, authors should avoid assigning XHTML-only CSS properties to SVG elements and vise-versa.

2.6.1: Introduction to XML Islands

This section defines a method of including generic XML markup in OPS Publications. The motivation is to achieve the maximum backwards, sideways, and forwards compatibility with other XML vocabularies, including Extended OEBPS, as defined in OEBPS 1.2.

This is consistent with the stated future directions of OEBPS 1.2.

To that end, this document introduces the idea of "XML Islands." Two variants exist:

• Out-Of-Line XML Islands
• Inline XML Islands

Out-Of-Line XML Islands are any complete XML document that is not authored in one of the Preferred Vocabularies (i.e. DTBook or XHTML) or uses an Extended Module in an otherwise Preferred Vocabulary document.

An Inline XML Island is an XML document fragment using a non-Preferred Vocabulary or using an Extended Module of a Preferred Vocabulary that exists within an XHTML Preferred Vocabulary document within an OPS Publication. Inline XML Islands are also namespace-qualified to the OPS namespace and are not contained within object elements.

Inline XML Islands must not be used within documents using the DTBook Preferred Vocabulary; they must only be used within XHTML documents.

2.6.2: Out-of-Line XML Islands

An Out-Of-Line XML Island is a complete XML document that is not authored in one of the Preferred Vocabularies or uses an Extended Module in an otherwise Preferred Vocabulary document. Including an Out-Of-Line XML Island requires several declarations in various parts of the Publication.

<?xml version="1.0"?>
<!DOCTYPE example SYSTEM "example.dtd">
<example>
   <title>This Is An Example</title>
   <paragraph>This is a paragraph with a <huge>big</huge> section
   of text that could be styled with OPS CSS!</paragraph>
</example>

...<a href="chapter2.xml">Chapter 2</a>...

        <chapter>
                <title>Chapter 2</title>
                ...
        </chapter>

<html>
        <head>
                <title>Chapter 2</title>
        </head>
        <body>
                ...
        </body>
</html>

<item href="chapter2.xml" id="chapter2"
      media-type="text/xml"
      required-namespace="http://www.example.com/chapter"
      fallback="chapter2fallback"/>
<item href="chapter2.html" id="chapter2fallback"
      media-type="application/xhtml+xml"/>

2.6.3: Inline XML Islands

An inline XML Island is an XML document fragment using a non-Preferred Vocabulary or using an Extended Module of a Preferred Vocabulary that exists within an XHTML Preferred Vocabulary document within an OPS Publication.

Processing Inline XML Islands is more complex than processing Out-Of-Line XML Islands, due to processing and display requirements. Out-Of-Line XML Islands are full XML documents, whose fallback options are defined in the OPF Package Document. Inline XML Islands are handled via a markup structure designed to simulate the common programming concept of a "switch" statement.

<ops:switch id="mathmlSwitch">

   <ops:case required-namespace="http://www.w3.org/1998/Math/MathML">
      <math xmlns="http://www.w3.org/1998/Math/MathML">
         <mrow>
            <mn>2</mn>
            <mo>&InvisibleTimes;</mo>
            <mi>x</mi>
         </mrow>
         <mrow>
            <mo>+</mo>
            <mi>y</mi>
            <mo>-</mo>
            <mi>z</mi>
         </mrow>
      </math>
   </ops:case>

   <ops:default>
      <p>2x + y - z</p>
   </ops:default>

</ops:switch>

<ops:switch id="XHTMLServerSideSwitch" xmlns:ops="http://www.idpf.org/2007/ops">
        <ops:case required-namespace="http://www.w3.org/1999/xhtml"
                required-modules="server-side-image-map">
                <a href="http://www.example.com/examplemap.map">
                <img src="example.gif" ismap="ismap"
                        title="Example Map"
                        alt="A picture of an example." />
                </a>
        </ops:case>
        <ops:default>
                <img src="example.gif" usemap="map"
                        title="Example Map"
                        alt="A picture of an example." />
                <map name="map">
                        <area href="example1.html"
                                alt="Link to the first example."
                                shape="rect" coords="0,0,118,28" />
                        <area href="example2.html"
                                alt="Link to the second example"
                                shape="rect" coords="184,0,276,28" />
                </map>
        </ops:default>
</ops:switch>

3.2.1: URI Values

For those properties that take a URI value, the URI must point to a document of appropriate media type for the property in question. All such referenced documents must be contained within the OPF Package Document’s manifest.

3.2.2: Integers and Real Numbers

Real numbers are denoted by number, integer values by integer. Either could have an optional sign value (one of "+" or "-"), though particular properties could restrict the ranges and sign of numeric values.

3.2.3: Length

All non-zero coordinate and size values must have specified units. All units defined by CSS1 and CSS2 are supported:

3.2.4: Percentages

Where percentage units are supported, they are used as defined for each property in the CSS specifications for which they are an allowed value.

3.2.5: Color

Current browsers support a host of keyword color names. XHTML 1.1 defines 16 named colors, as well as numeric values. OPS style sheets may use all CSS2 forms, however Reading Systems are not required to distinguish all these colors for rendering (otherwise monochrome devices would necessarily be non-conforming, which is not the intent).

3.2.6: Time

Units defined by CSS2 are supported:

3.2.7: Frequency

Units defined by CSS2 are supported:

3.2.8: Strings

Strings must be quoted using either single or double quotes (Unicode codes 39 or 34, respectively). Nested strings must be escaped with a backslash (e.g. " a \"nested\" string"). To embed a line break in a string, use the escape "\A". The hexadecimal "A" is the line feed character in Unicode, but represents the generic notion of "newline" in CSS.