Click here for the Creating NIMAS Files document in Microsoft Word format

On this page:

1. The NIMAS fileset
2. Creating a NIMAS-conformant XML content file
   1. well-formed XML documents
   2. valid NIMAS-conformant XML files
   3. DAISY 2005-specific items
   4. best practices
   5. NIMAS 1.1 DTD required attributes
3. Validating a NIMAS-conformant XML content file
4. Preparing images for a NIMAS fileset
   1. image files
   2. organization of images
   3. value-added components: mark-up of images
   4. value-added components: writing alt text and LDs
   5. images and mark-up of math content
5. Preparing a package file (OPF)
   1. MIME (Multipurpose Internet Mail Extension)
   2. MIME types
   3. NIMAS filesets and MIME types
   4. NIMAC and metadata
6. PDF pages
7. Best practices
   1. identifying levels' content type
   2. levels and class attributes
   3. page numbers absent
   4. sidebars
   5. tables
   6. tables of contents
   7. write-on lines (WOLs) or fill-in-the-blank lines
   8. text in images
   9. NIMAS filesets common errors
   10. corrections to NIMAS filesets

1. The NIMAS fileset

A NIMAS fileset consists of the following:

• XML content file,
• a package file (OPF),
• a PDF-format copy of title page and ISBN and copyright information pages, and
• a full set of content images in SVG, JPG, or PNG format.

A NIMAS fileset is a set of source files that may be rendered into a variety of output formats, including student-ready versions such as audio books, Braille editions, etc. It is not a post-production product; it is a pre-production product. NIMAS files are intended for use by publishers, authorized entities, and others to produce accessible versions of printed instructional materials. They are not intended to be used as-is and should not be considered finished products. XML content files in NIMAS filesets must be conformant to the NIMAS 1.1 specification, a sub-set of the DAISY 2005-2 DTD. By definition, a NIMAS XML file will validate to the NIMAS 1.1 DTD.

See the History and Core Technologies document for more information on the background of NIMAS and NIMAS files.

2. Creating a NIMAS-conformant XML content file

A NIMAS-conformant XML content file is an XML file that validates against the NIMAS DTD. What this means is that the file is consistent with the requirements of specific NIMAS DTD items. A NIMAS-conformant XML file qualifies as a well-formed XML document. Anyone new to NIMAS should begin by creating a well-formed XML file and continue from there to create a NIMAS file. Well-formed means that all of the XML is correct. For example, it's analogous to writing that is grammatically correct. In the same way that correct writing does not have spelling errors, punctuation errors, syntax errors, and the like; well-formed XML does not have nesting errors, opening- or closing-tag errors, or syntax errors. A well-formed XML document is a basic, correct file; a NIMAS-conformant XML file is a correct file using XML specific to the NIMAS DTD.

There are many XML editors available on the market, and it would probably be best for anyone new to XML to create files using one of these. (Although it is possible to create perfectly good XML with a simple text editor such as Notepad or TextPad.) Examples of XML editors include Dreamweaver, XMLSpy, XMLmind, <oXygen/>. These editors will 'test' an XML document for errors and let you know whether a document is well-formed or if it validates to a specific DTD that is listed in an XML declaration. Many editors will also point out where, or approximately where, an error has occurred. The larger an XML document is, the more valuable this function is. The best way to create good XML files is simply to begin. The following tips may prove useful.

More information is available throughout this web site, in the NIMAS Technical Specification, and in the DAISY Structure Guidelines.

To create well-formed XML documents, keep the following in mind:

• All non-empty elements must have both an opening and a closing tag
• Check that you have both halves of any pair (for example, in class="xyz" make sure both double quotes are present)
• Check that the slashes in your tags are facing the right way (example: /)
• All elements must be properly nested, i.e., with their opening and closing tags within the same parent element
• A good XML document must have a declaration (example: <!DOCTYPE dtbook PUBLIC "-//NISO//DTD dtbook 2005-2//EN" "http://www.daisy.org/z3986/2005/dtbook-2005-2.dtd">)
• Make sure your comment tags are correctly coded and enclose the correct content
• XML is a precision code; check that there are no typos in your tags

To create valid NIMAS-conformant XML files, keep the following in mind:

• Images: an alt text placeholder is required (including actual alt tag text is recommended); leaving the value of the alt attribute blank is acceptable as a placeholder (example: <img id="1.01.23" alt=""/>)
  • alt is a required child attribute of the <img> element
• Formatting and styling should not be done with tags in an XML file
• <lic> is optional/not required in <list>s
• Check that image filename references in the XML are exactly the same as actual image filenames
• Make sure that you have used the correct tag (example: <img> is a valid tag, but <image> is not)
• Currently, long descriptions of elements are contained in <prodnote> tags
• If you have a well-formed XML document that yet won't validate to the NIMAS DTD, first check that you are not using any elements in the wrong location; for example, are all elements permitted as child elements of the ones within which they are nested?
• Remember that a NIMAS XML file is a source file; it won't necessarily render in a browser

Since NIMAS files align with the DAISY standard, the following DAISY 2005-specific items should be kept in mind:

• The <sidebar> and <prodnote> elements must include a render attribute set to either required or optional (example: <sidebar render="optional">)
• Block elements are not permitted as child elements of <frontmatter> <bodymatter>, or <rearmatter>
• A <div> element must be contained within a level element (examples: <level>, <level1>, <level2>)
• The following elements have been deleted from the DAISY 2005-2 DTD: <hr>, <levelhead>, <notice>, <style>
• The following elements have been added: <bridgehead>, <byline>, <covertitle>, <dateline>, <epigraph>, <linegroup>, <poem>

The following items are suggested best practices for NIMAS/DAISY XML files:

• All images must have a placeholder for alt text or, if possible, alt text itself. Ideally, complex images, images with more than one meaning or context, and instructionally important images should also have long descriptions (LDs).
• If a word breaks between pages, leaving a hyphenated word at the bottom of one page and the top of the next, remove the hyphen and include the whole word at the end of the first of the two pages.
• Use a leveled numbering convention (example: <p id="L001.002.P001">) when preparing projects where all content will be in files (textbooks, etc.). This enables content to be added to, removed from, or moved within XML files at any point in their creation process. Aside from preventing re-numbering of large portions of content, it is also useful for structuring, managing, and manipulating the content of XML files (examples: implementing a change to recurring portions of content without affecting other content; updating content without having to make XML mark-up changes to content that will remain unchanged; enables fast-tracking, where production begins before content is finalized).
• It is recommended that filesets be compressed or zipped to reduce their size.

NIMAS 1.1 DTD Required Elements

Following is a list of elements that are required (taken from the NIMAS Technical Specification)—other elements may be required if applicable to content.

required elements	description
<dtbook>	The root element in a Digital Talking Book DTD. <dtbook> contains metadata in <head> and the contents itself in <book>.
<head>	Contains metainformation about the book but no actual content of the book itself, which is placed in <book>. This information is consonant with the <head> information in XHTML, (see XHTML11STRICT). Other miscellaneous elements can occur before and after the required <title>. By convention, <title> should occur first.
<book>	Surrounds the actual content of the document, which is divided into <frontmatter>, <bodymatter>, and <rearmatter>. <head>, which contains metadata, precedes <book>.
<meta>	Indicates metadata about the book. It is an empty element that may appear repeatedly only in <head>. Metadata may appear in the OPF file instead.
<title>	Contains the title of the book but is used only as metainformation in <head>. Use <doctitle> within <frontmatter> for the actual book title, which will usually be the same.

NIMAS 1.1 DTD required attributes

Following is a list of attributes that are required if the noted elements are used.

required attributes	examples
version on <dtbook>	<dtbook version="2005-2">
src and alt on <img>	<img src="./images/U01C04/p036-003.jpg" alt="photo of an apple"/>
type on <list>	<list type="ol">
render on <prodnote> and <sidebar>	<prodnote render="optional">
id on <pagenum>, <note>, and <annotation>	<note id="U01C04.002">
idref on <noteref>, <annoref>	<noteref idref="0114-012">
content on <meta>	<meta content="2007">
dir on <bdo>	<bdo dir="rtl">

3. Validating a NIMAS-conformant XML content file

An XML file must validate to the NIMAS 1.1 DTD (derived from DAISY 2005-2) to be considered NIMAS-conformant. To validate a NIMAS XML file, add the following declaration to the top of the XML file:

<!DOCTYPE dtbook PUBLIC "-//NISO//DTD dtbook 2005-2//EN" "http://www.daisy.org/z3986/2005/dtbook-2005-2.dtd">

Once the XML file is completed, test it to see if it validates against the DTD. In an XML editor, use the validate function; otherwise, use an online validator:

• In XMLSpy, use the Check well-formedness and Validate file functions (yellow and green checkmark icons, or F7 and F8, respectively)
• In Dreamweaver, use Validate as XML (under the File pull-down menu, then under Check Page)
• In <oXygen>, use the Check XML Form and Validate as you type functions (add the NIMAS DTD first using the MyValidator tool)
• At HTML/XHTML/DocBook XML Validator and Transformer online, follow the on-screen instructions
• At Scholarly Technology Group's XML Validation Form online, copy and paste XML into the text field or use the local file field for large documents
• At the W3C's web site, copy and paste XML into the text field or use the local file field for large documents

A validator has been developed by the NIMAC repository contractor to ensure that NIMAS XML content files submitted to the national repository are valid and a client version is available to qualified publishers so that files may be tested prior to submission to the NIMAC.

See the XML Editors and Validation section of the NIMAS site's Content Development and Design page for more information.

In order to view a complete NIMAS file and confirm that images are placed in the appropriate sequence, change the file extension from -.xml to -.html and add a reference to a css file within <head>. Close the document, and open it in a browser. Such an extension-only version should only be used as a visual representation of the XML files as an aid to production: such a version is not a true HTML file, is not a student-ready version, and should not be used in place of these. Any HTML version of a NIMAS fileset intended for use by students or in other post-production capacities should be transformed with appropriate code to HTML or XHTML (software and XSLT transformations for doing this are freely available from the DAISY consortium).

4. Preparing images for a NIMAS fileset

The Technology Working Group of the NIMAS Development Committee has recommended the following:

Image files

• All of the images included within a work should be provided in folders within the NIMAS fileset.
• XML content files should include an "img" element corresponding to each use of an image.
• "src" attributes of img tags should contain a reference to the appropriate image's filename. This reference is a relative pathname (example: <img id="staricon4" src="./images/U10C02/staricon4.jpg" alt="star icon"/>
• Preferred image type is SVG, next is either PNG or JPG format
• SVG images should be provided with height and width attributes within a source XML file as guidance for producers and to allow images to be displayed correctly. Information about the original size of an image, either in the SVG or in the XML, is useful to producers for several purposes.
• PNG and JPG images should be provided at a resolution of 300 dots per inch (dpi), based on their actual size in the printed work, so a 2" x 1" image would be 600 x 300 pixels.

Organization of images

To simplify images organization and to recommend an efficient way to handle images for use with NIMAS files, the following is recommended:

All images should be saved in an images folder:

Within this parent folder, images should be saved as follows:
= frontmatter
The zeros allow for sequential ordering.

– = bodymatter and rearmatter
Naming here provides information about image location to unit and chapter level.

Naming here provides for the fact that many works contain images that recur throughout content at all levels.

Examples

An icon that occurs several times in frontmatter and twice per chapter in bodymatter:

A folder of images occurring in the middle of a work:

An image that occurs in the frontmatter of a work:

Go to CAST's NIMAS Exemplars page to see examples of NIMAS-conformant files that include proper handling of images within a NIMAS-conformant fileset.

Value-added components: mark-up of images using previously-published (print) materials

When marking up images from a previously-published, print-based source, it is recommended that images be named according to their placement within original source content. Create filenames based on an image's page location and sequential order. Example:

p004-002.jpg
An image with this filename appears on page 4 of the original work and is the 2^nd image on that page.

Do not use spaces in image filenames.

Choose an image's sequential order number according to its position: name image files from top to bottom and from left to right. Example:

Occasionally it will not be entirely obvious which layout position an image holds. In such cases, simply choose a logical sequence number and make a note of it for production.

Value-added components: writing alternative text and long descriptions

An alt text placeholder for images is required (example: <img alt=""/>), and including actual alt tag text is strongly recommended to publishers, as is including (when appropriate) long descriptions. The alt attribute is part of the <img> element and text is placed in standard attribute format (example: <img alt="text" />). The <prodnote> element is used for images long descriptions in the NIMAS 1.1 DTD (example: <prodnote>Text of long description.</prodnote>). Alt tags and long descriptions are especially important for math equations that will be provided as images temporarily* but will not be accessible to screen readers and other devices without inclusion of an alternate representation.

The following is taken from Editorial Process Guidelines for Creating Accessible Digital Textbooks (CAST, Inc., 2004).

Writing for Accessibility: Alt Tags and Long Descriptions
An alt tag is a brief description of an image. The "alt" in alt tag stands for "alternative" and an alt tag is alternative text—another option to the image. Alt tags should state the type of image and a brief summary of the image. They should not have any unnecessary text. Alt tag text should be approximately four to ten words long. Alt tag text is designed to be brief. The point is to capture the function of the graphic and to express it in terms that make sense.

Every image has an alt tag associated with it. An alt tag must appear for every purposeful image. The alt tags appear on screen with mouse-over, or when the mouse is moved over the image. Assistive technology such as a voice-output screen-reader will not "read" an image but will read the alt tag instead. Text-only browsers display alt tags over the image placeholder.

A long description is a detailed description of an image that supports or adds meaning to the text. Long descriptions are context-specific. The details given depend on how the image supports or supplements the text. Their purpose is to provide content information conveyed by the image so that students who are unable to "read" the image, for whatever reason, still have access to the information relevant to instruction that is conveyed by the image.

Long descriptions are provided whenever an alt tag is not sufficient to convey the content of an image. Long descriptions should be written for each image (map, timeline, picture, chart, graph, photo, etc.) that supports the text or gives additional or new information needed to understand content or topic. A long description should be included whenever an alt tag cannot provide sufficient information about the object and its purpose for inclusion. Remember that long descriptions vary according to learning goals. Try to create a balance between brevity and sufficient information so that every learner can access key content.

Note: There is no limit to the length of a long description; LDs should be as long as necessary to convey image information.

Images and mark-up of math content

Currently, a standard, problem-free way to treat mathematical content in terms of NIMAS mark-up has not yet been determined. The XML specification MathML has been formally accepted by the DAISY Consortium as a modular extension for mathematical content. MathML is therefore a part of the optional element set of the NIMAS specification. Producers are encouraged to begin using MathML where feasible. As an interim solution, where the use of MathML is not yet possible, math equations and other symbolic content should be presented as images with alternative text and long descriptions. When creating math content images, it is crucial to distinguish between content such as in-line equations, that are math content per se, and images, such as graphs, that just so happen to contain math content. The suggested best-practice for accomplishing this distinction is to code true math content with the notation EQ in their image filenames to indicate that an image represents math content. Images such as charts and illustrations that contain or are about math should be coded as any other image would be. Examples are as follows:

Filename of an image of an in-line equation: EQp212-004.jpg

Filename of a pie chart: p010-002.jpg

Filename of a symbol presented within text: EQp005-003.jpg

Filename of an icon used throughout a math textbook: staricon.jpg

Filename of an equation that recurs throughout a unit: EQdifferential2.jpg

A text description of EQ images must be provided for, either with alt tag placeholders or alt tag text and/or long description text. Coding in-line math content as images temporarily will make it accessible, because text descriptions will be recognized and read by text-to-speech software/readers.

See the Math Resources page for more information.

5. Preparing a package file (OPF)

Package files created for use with NIMAS XML files must conform to the oebps 1.2 standard (the Open eBook Publication Structure Specification Version 1.2), i.e., validate to this specification. The following information about the oebps 1.2 Specification is based on information made available to the public by the International Digital Publishing Forum.* NIMAS package files should validate to this oebps standard, i.e., these files are NIMAS OPF files, not DAISY OPF files. Additional enhancements will be necessary for a file to validate as a DAISY OPF.

Currently, NIMAS 1.1 includes two metadata elements that were created for future use but turned out not to be needed in practice and that are intended to be phased out as the technical specification is updated. However, these two items are part of NIMAS 1.1 and are therefore required. For all OPF files conforming to NIMAS 1.1, these metadata elements should be included yet left blank:

<meta name="nimas-SourceEdition" content=""/>
<meta name="nimas-SourceDate" content=""/>

NIMAS filesets must also meet metadata submission requirements for the National Intstructional Materials Access Center (NIMAC), the national repository of NIMAS filesets. The NIMAC provides a comprehensive sample, instructions, and details at their NIMAC Metadata web site page. A sample NIMAC-valid OPF file is available through a link from that page, and may also be downloaded from the NIMAS site's Exemplars page (exemplar 9). All of the NIMAS exemplar filesets include OPF files that are valid to the NIMAS specification and to NIMAC submission requirements.

The current oebps 1.2 declaration for an OPF file is as follows:

<!DOCTYPE package PUBLIC "+//ISBN 0-9673008-1-9//DTD OEB 1.2 Package//EN" "http://openebook.org/dtds/oeb-1.2/oebpkg12.dtd">

To create valid package files, keep the following in mind:

• Use the -.opf extension
• The package file must include a list of all files relating to a single publication
• Package files are text/xml files
• Package files must be well-formed XML
• Package files must have a unique-identifier attribute (example: <package unique-identifier="1234">) and this is mirrored in the Identifier metadata tag (example: <dc:Identifier id="1234">ABC</dc:Identifier>)
• Use Dublin Core (example: <dc:Text>) metadata tags

From the oebps specification publication:

MIME (Multipurpose Internet Mail Extension)

MIME Types
MIME types are standard format extensions used to support the attaching of non-text files to standard Internet mail messages. Non-text files include graphics, spreadsheets, formatted word-processor documents, and sound files. The MIME standard specifies the type of file being sent and the method that should be used to turn it back into its original form.

Manifest list items in OPF files should include standard MIME types in order to be fully accurate. For example, <item id="idname" href="filename.xml" media-type="text/xml"/> where text in media-type="text/xml" is a standard MIME type and xml in media-type="text/xml" is a standard sub-type. Another example is <item id="idname" href="path/path/filename.jpeg" media-type="image/jpeg"/> where image in media-type="image/jpeg" is a standard MIME type and jpeg in media-type="image/jpeg" is a standard sub-type.

The main types are application, audio, example, image, message, model, multipart, text, and video. Sub-types are extensive for each type, but, for example, the most common ones for image are gif, jpeg, png, and tiff; and for text are css, html, plain, richtext, and xml. Lists of types are available at http://www.iana.org/assignments/media-types/. Other MIME information is readily available over the Internet: type "MIME types" into a search engine.

NIMAS Filesets and MIME Types
MIME types for use with NIMAS filesets reflect the NIMAS' alignment with DAISY and follow the guidelines of Z39.86-2005, section 3.3 (http://www.daisy.org/z3986/2005/z3986-2005.html#Manifest). They are as follows:

XML content files: media-type="application/x-dtbook+xml"
A full reference/OPF manifest item would read as follows:
<item id="xmlexemplar" href="contentfilename.xml" media-type="application/x-dtbook+xml"/>

PDF files: media-type="application/pdf"
A full reference/OPF manifest item would read as follows:
<item id="copyrightpagepdf" href="copyrightpage.pdf" media-type="application/pdf"/>

images: media-type="image/jpeg" or media-type="image/svg+xml" or media-type="image/png"
A full reference/OPF manifest item would read as follows:
<item id="imgarrow" href="images/U00C00/arrow.jpg" media-type="image/jpeg"/>
or
<item id="imgarrow" href="images/U00C00/arrow.svg" media-type="image/svg+xml"/>
or
<item id="imgarrow" href="images/U00C00/arrow.png" media-type="image/png"/>

NOTE: The DAISY DTD on which the NIMAS technical specification is based does not include all possible MIME media types and sub-types because official types are not a static, permanent list but evolve through the coordination of the Internet Assigned Numbers Authority (IANA).

NIMAC and Metadata
The NIMAC is the national repository for NIMAS files, managed by the American Printing House for the Blind (APH). There are additional metadata requirements for OPF files submitted to the NIMAC beyond those required for NIMAS OPF files. Those differences facilitate the storage, management, and retrieval of NIMAS files. The NIMAC web site has its own metadata page, and a NIMAC sample OPF file that includes both NIMAC and NIMAS metadata requirements is available there (full version with history and comments) and on CAST's NIMAS Exemplars page (Word and XML versions; separate history and comments document). As noted above, all of the NIMAS exemplar filesets include OPF files that are valid to both the NIMAS specification and NIMAC submission requirements.

For quality control purposes, the NIMAC needs to receive from publishers a PDF of both the title page and the copyright/ISBN page for the book. Because the NIMAC staff has found that the XML file for a work may not always include all series, state edition, ISBN, or other essential metadata, the PDF helps ensure that the metadata submitted in the OPF is accurate, complete, and describes the actual file being submitted. Since the NIMAC does not have access to any print copies of works, these PDF pages provide the best, and in some cases the only, way to compare key metadata provided with the the print version.

An important point that has come up regarding fileset submission to the NIMAC concerns discrete item identification information. In rare instances, a work submitted to the NIMAC may use a UPC code for unique identification rather than an ISBN. In these cases (and only these cases) where UPC information is the only source of unique item identification, UPC information should be contained in the <dc:Identifier> element. The format for this usage is "UPC23443562NIMAS" where "UPC" prefaces the UPC numeric code itself and "NIMAS" follows, without punctuation or spaces. Note that the <dc:Source> element is for ISBN information only and must not be used for these exceptions.

6. PDF pages

In NIMAS fileset submission, the NIMAC needs to receive PDF pages of both title and copyright/ISBN page(s) for a book. If copyright/ISBN (unique identification information) appears elsewhere, those page(s) must also be included.

Because the NIMAC has found that submitted XML (source) files are not always complete and may omit essential metadata such as ISBN information, these noted PDF pages help ensure that submitted files can be completed, are accurate, and describe submitted filesets. Since the NIMAC does not have access to print copies of books, these PDF pages provide the best, and, in some cases, only, way to compare provided metadata with a print version.

7. Best practices

Implementation of the NIMAS and the corresponding increase in NIMAS filesets and their submission to the NIMAC have brought questions to light regarding practical implementation of the Standard. Several items of interest have been discussed as implementation has progressed, and, best practices—determined by consensus of members of the NIMAS Technical Assistance and Development centers—are outlined below.

Identifying levels' content type

The <level> element (heavily used in NIMAS XML source files), does not contain discrete information about the type of content it contains. For example, an XML source file may contain units and chapters, another may contain chapters only, or a third units, chapters, and sections. However, it is very useful for producers, transcribers, and end users to be able to know where they are (conceptual level) when encountering segments (structural level) in a work. This information can be provided in two ways:

1. include class attributes and id's with <level> elements:
   

   XML:	Output (through XSLT/CSS/etc.):
   <level class="chapter" id="02.02">Weather</level>	Chapter 2: Weather
   <level class="chapter" id="02.03">Climate</level>	Chapter 3: Climate

2. include content type within <level> content:

   XML:	Output:
   <level2>Chapter 2: Weather</level2>	Chapter 2: Weather
   <level2>Chapter 3: Climate</level2>	Chapter 3: Climate

Note: Bear in mind that the above examples are meant to illustrate a specific idea. They do not contain full mark-up, such as a complex id structure, because that would not serve the purpose of this example.

Levels and class attributes

It will often be necessary to use class attributes with level elements (<level1>, etc.) It is important to note that the more specialized class attributes are, the less useful an XML source file is. It is a mistake to use class attributes that are specific to a particular work. As an aside, do not use spaces in attributes. Please compare the following:

<level4 class="subsection">      vs.      <level4 class="Biographies">

While it would be possible, of course, to use a class attribute such as "Biographies" it would count as an error because it would at least in part defeat the purpose of the XML, which is to create a source file useful in a variety of ways.

Using a consistent attribute list is helpful and efficient for anyone creating more than one XML work. The attribute "subsection" would be useful across many books, for example, where the attribute "Biographies" may only be useful in one book. XSL using "subsection" could be re-used, but work done to transform or render XML with one-off attributes would not be reusable.

If desired, one way to obtain description information embedded in a file is to use part of the id attribute for this purpose instead. Id attributes are much more suitable for this purpose for the obvious reasons. However, the ids will almost certainly be used for other things besides finding out what kind of content is in the item, so the goal is to include without excluding. See the following example, where "Bio" is a descriptive indicator and "sub1245" is the rest of the id attribute.

<level4 class="subsection" id="sub1245Bio">

NIMAC and metadata

Please see the last paragraph of the NIMAC and metadata section for important information regarding UPC codes used as unique identification.

Page numbers absent

Occasionally source material will not have page numbers of any kind. Examples of instructional materials that may be created without printed page numbers include blackline masters, transparencies, worksheets. Yet the use of <pagenum> is necessary to distinguish one physical page from another. In such a case it is acceptable to use another available sequential number in place of the absent page number. Examples of such numbers include a unique product code; unique lesson, unit, and item (or similar) information present in a printed header or footer. These items permit the indication of sequence in a way comparable to page number.

Examples:
<pagenum>1136-8</pagenum>, <pagenum>1136-9</pagenum>, <pagenum>1136-10</pagenum>
<pagenum>Transparency7.2B</pagenum>, <pagenum>Transparency7.2C</pagenum>
<pagenum>12-SectionSpinners</pagenum>, <pagenum>16-SectionSpinners</pagenum>
<pagenum>4581-3A</pagenum>, <pagenum>4581-3B</pagenum>, <pagenum>4581-3C</pagenum>

Sidebars

Questions have been posed to the NIMAS Technical Assistance Center regarding <sidebar> content that is sectioned and, in some cases, subtitled. It is inappropriate to use <div>s for this purpose. One way to code content structured in such a way is illustrated as follows:

<sidebar render="required">
<hd>El Grande Lado</hd>
<p class="side01.01">texto<p>
<hd class "sidebarsub01">Lado Pequeno</hd>
<p class "side02.01">texto</p>
<p class "side02.02"> texto</p>
<hd class "sidebarsub02">Lado Minisculo</hd>
<p class "side03.01"> texto</p>
<p class "side03.02"> texto</p>
</sidebar>

The <sidebar> element is relatively versatile in that it may contain, for example, numerous <hd>s; <blockquote>, <list>, or even another <sidebar>. However, one potential drawback is that if subheaders are not explicitly tied to their accompanying texts, there will be no way to style sections differently from each other through the use of CSS.

Tables

When a table spans more than one page of a printed work, it is recommended to put all page numbers in (separate) <pagenum>s prior to the start of the <table>; so a table that spanned three pages would have three <pagenum>s and then an opening <table> tag. Producers are also advised to add a <prodnote> that explains the page span, and a good location for this would be below <pagenum>(s) and above <table>. Example:

<pagenum id="p008" page="normal">8</pagenum>
<pagenum id="p009" page="normal">9</pagenum>
<pagenum id="p010" page="normal">10</pagenum>
<prodnote id="002.001.T04" render="required">Please note that the following table spans three pages of the print source work.</prodnote>
<table>

Tables of contents

A table of contents (TOC) should be created as part of the NIMAS 1.1 source file for each print work that contains a TOC. The <list> element should be used to create this. Please note that conversion tools are able to generate TOCs only if the underlying source XML is correctly added to the source content.

An index or a TOC is the kind of content where <lic> (list item component) would sometimes be used; but, since <lic> is not universally recognized, it is recommended that class attributes be used with <li> (list item) instead as shown in the following example.

<li class="entry">, <li class="page">

Write-on lines (WOLs) or fill-in-the-blank lines

The NIMAS Technical Assistance Center has received several inquiries regarding the proper way to indicate the presence of write-on lines (WOLs) or fill-in-the-blank lines in NIMAS source files. Currently there is not a specific element for this in the NIMAS 1.1 element set nor in DAISY2005. That being the case, it is acceptable to use a continuous series of underscore characters for this purpose. To match the level of granularity at which WOLs occur, it is recommended to code the characters as shown:

<span class="WOL">__________</span>
or
<span class="blankline">__________</span>

Text in Images

Instructional content should be provided in an alternate format to images. Text in images calls for thoughtful analysis of the image(s) in question because there is more than one kind of this type of image, each calling for different handling. A person who knows the content of the textbook is the best person to decide which kind of image with text is being handled and how to mark it up for accessibility.

The key to choosing whether or not to mark up text in images as alt and LD text or as body text is to determine whether or not the text is an integral part of the image (chart; map = alt and LD), whether the content is presented visually for variety or other noninstructional reason (some icons; repeated reminders = alt), and whether or not the text would stand alone if its image were not present (menu; scorecard = body text).

This last point of whether or not embedded image text could stand alone without its visual is an important one since image-dependent embedded text must remain part of its image (as a long description) in order for the text to retain its meaning and stand-alone embedded text is often far more accessible if converted into body text because image-independent embedded text is, effectively, body text presented visually. The last two examples of those below show one of each case.

These and similar factors should determine specific mark-up of image text. A few examples of images with embedded text and appropriate ways to mark them up is shown below.

image type	best practice	description	example alt tag text	example LD or body text
Maps	Provide an alt tag and a long description (LD)	Image of the state of Arizona with the capital indicated	Map of Arizona	This map of Arizona shows the state's outline, with a long, straight line as its eastern border; a square southeastern corner; a diagonal line going up in a northwestern direction showing its southern border; a curved, irregular line showing its western border; and a straight line showing its northern border. The capital city of Phoenix, in the central southern half, is marked with a red star.
Icons	Icons with noninstructional text should be given an alt tag that provides the text	Image of a checkmark with text "Check Your Work!" embedded in it	alt="Check Your Work! icon" OR alt="Checkmark icon labeled 'Check Your Work!'"
	Icons with instructional text should be given an alt tag and instructional text should be pulled out into body content as a sidebar, paragraph, or other appropriate content component	Image of a computer with text "Use resources 12 and 14 from CD 1 for this assignment" embedded in it	alt="Computer icon"	<sidebar render="required"> <p id="001.02.ictxt">Use resources 12 and 14 from CD 1 for this assignment."</p> </sidebar>
Photos, drawings, paintings, illustrations, etc.	Photos or illustrations with instructional text should be given an alt tag and an LD, and instructional text should be pulled out into body content as a sidebar, paragraph, or other appropriate content component	Image of a tomato plant with text labels	alt="Drawing of a tomato plant with labeled parts"	This drawing of a tomato plant shows a tall green stem with many six-pointed leaves and three round, red tomatoes. The roots of the plant are drawn in brown beneath the sandy soil. The parts of the tomato plant are labeled, with "roots" next to the plant's roots, "stem" and "leaves" next to the green stem and leaves, and "fruit" next to the round tomatoes.
		Image of a cartoon dog reading a poster with instructions	alt="Illustration of a dog reading an instructions poster"	<sidebar render="required"> <hd id="001.04.01.imgtxt"> Make Your Own Smoothie!</hd> <p id="001.04.01.imgtxt">Make your own healthy and delicious smoothie for lunch or a snack.</p> <p id="001.04.02.imgtxt">Put the following ingredients into a blender:</p> <list id="001.04.01.imgtxt" type="ol"> <li>1 cup strawberries</li> <li>1/2 cup vanilla yoghurt</li> <li>2 tblsp protein powder</li> <li>1 cup milk</li> </list> <p id="001.04.03.imgtxt">Put the lid of the blender on and blend ingredients together at a medium speed for 30 to 40 seconds. Pour into a large glass and serve with a straw.</p> </sidebar>

NIMAS filesets common errors

As use of the NIMAC increases, AMPs are finding several errors in filesets that seem to occur more often than necessary. Below is a list of commonly found errors for publishers and other preparers of NIMAS filesets to watch out for:

• Pages missing or out of order
  • check pagination before fileset submission
  • do not use a national edition source file and simply copy and paste state edition pages into it; carefully check pages and page numbers
  • check tables of contents against content itself
• Images missing
  • check that all images appearing in a print work are included as part of that work's NIMAS fileset (required by the Standard)
  • check that all actual image files have corresponding code in the correct location within the work's XML file
• Tables
  • Ensure that tables are coded as tables within the XML source file and are not presented as images; in rare instances images are made up of content presented visually as tables but by far the vast majority of tables are and should be coded using <table> and its associated elements
• Lists
  • Ensure that lists have been formatted correctly by checking the <list> element's style attribute and the <li> elements' content (for example, adding numbers to a list that uses the "ol" attribute would result in duplicate numbering)

Corrections to Filesets

If corrections are made to a published work after a NIMAS fileset for that work has been submitted to the NIMAC, those same corrections should be made to the NIMAS files and a new fileset submitted to replace the original. If changes to a work are minimal or cosmetic in nature, it is not necessary to resubmit a replacement fileset to the NIMAC.

 

Go to CAST's NIMAS Exemplars page to see examples of NIMAS-conformant files that include appropriate package files within a NIMAS-conformant file set.

<OeB> Open eBook Forum
Click here to go directly to the OEBPS 1.2 specification.

Opening the eBook, by Didier Martin. (2000.) XML.com.
This article explains the OEBPS standard using IDPF content, but in a more readable style than the spec itself. Note that the OEBPS standard has been updated from 1.0 to 1.2 since the article's publication.

 

Changes were made to this document as of March 8, 2007:

• TOC, addition
• well-formed XML documents list, clarified
• valid NIMAS-conformant XML files list, clarified
• DAISY 2005-specific items list, clarified
• best practices list, addition
• NIMAS 1.1 DTD required elements table, addition
• NIMAS 1.1 DTD required attributes table, correction
• Section 3 NIMAC validator paragraph, updated
• Section 4 paragraph 1, updated
• Section 4 image files list, clarified
• Section 5 paragraph 1, addition
• NIMAS Filesets and MIME types section, addition
• NIMAC and Metadata section, addition
• Section 6, addition

Changes were made to this document as of June 22, 2007:

• Preparing a package file (OPF) section, addition
• NIMAC and Metadata section, addition

Changes were made to this document as of August 22, 2007:

• Preparing a package file (OPF) section, addition
• NIMAC and Metadata section, addition
• Section 7, addition

Changes were made to this document as of December 10, 2007:

• Best Practices section, addition

Changes were made to this document as of January 4, 2008:

• Preparing images for a NIMAS fileset section, updated
• Value-added components: writing alternative text and long descriptions section, updated
• Images and mark-up of math content section, updated
• Best Practices section, addition

Changes were made to this document as of March 25, 2008:

• Preparing a package file (OPF) section, addition
• Best Practices section, addition