This site will be taken down on August 1, 2015.

Please visit our new site at for updated content and new resources related to accessible educational materials.

Creating NIMAS Files

This guide is intended to help publishers and conversion houses to respond to state and local education agency requirements to prepare NIMAS filesets when textbooks are adopted or purchased.

The Opens new windowCreating NIMAS Files document is also available in 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
    6. DTD and OPF references
  3. Validating a NIMAS-conformant XML content file
  4. Character Encoding (UTF-8 and UTF-16)
  5. 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
  6. Preparing a package file (OPF)
    1. MIME (Multipurpose Internet Mail Extension)
    2. MIME types
    3. NIMAS filesets and MIME types
    4. NIMAC and metadata
  7. PDF pages
  8. Document updates (2007–present)

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.

A print work's XML content file includes all of the content found in its print version, including frontmatter, such as tables of contents and prefaces; backmatter, such as epilogues and indices; front and back covers, if they include content that is not presented elsewhere; and bodymatter, such as chapters and sections text, images, charts, tables, etc. Essential information about a print work should be included in its XML content file as well as in its OPF file to ensure that such information is available whether a fileset's OPF is utilized practically or not; such information typically includes a work's title, author(s), publisher, copyright, and ISBN, and may include other similar items. A print work's package file includes metadata about the content of the print work, including its images, as well as that required by the NIMAC for submission to its repository. Required PDF-format pages provide a necessary way for users of the fileset to ensure it's accuracy and completeness as well as providing a way to verify the work itself. Images present in the print work must be included in its fileset (see below for additional information regarding images).

See the History and Core Technologies page 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 Opens new windowDAISY 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-3//EN" "">)
  • 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.


For more specific best practices recommendations based on NIMAS implementation and the NIMAS Technical Assistance Center technical support, see the NIMAS Files Best Practices document.

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 elementsdescription
<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 attributesexamples
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">


DTD and OPF references

While recognizing that the current NIMAS Technical Specification permits use of DAISY/NISO Z39.86 2005 (1) and later (-2 and -3) as the XML source file DTD reference, the NIMAS Center strongly urges the use of the most current DTD in NIMAS filesets.  The most current DTD may be found here: Opens new window

The components of a fileset should be evaluated according to the NIMAS Technical Specification (currently v1.1), a sub-set of the DAISY ANSI/NISO Z39.86 standard.  Relevant language regarding references and validation are as follows (the entire document is available at the AIM web site:

"NIMAS-conformant content must be valid to the NIMAS 1.1 [see DAISY/NISO Z39.86 2005 or subsequent revisions]."
"Use of the most current standard is recommended."
"The package file is based on the Open eBook Publication Structure 1.2 package file specification (For most recent detail please see Opens new window A NIMAS package file must be a valid XML OeBPS 1.2 package file instance...."

As an extensible specification, the NIMAS Technical Specification was written to provide some flexibility as well as to state that updates and additions are and would be ongoing.  The NIMAS is based upon ANSI/NISO Z39.86, which, as a NISO standard, and “all NISO standards undergo a review and maintenance cycle” (Opens new window, the NIMAS must remain conformant to that standard.

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-3//EN" "">

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 Opens new windowHTML/XHTML/DocBook XML Validator and Transformer online, follow the on-screen instructions
  • At Opens new windowScholarly 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 Opens new windowW3C'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. Character Encoding (UTF-8 and UTF-16)

The Technical Assistance Center has received queries regarding encoding, as UTF-8 and UTF-16 are strongly recommended but not absolutely required by the technical specification. To clarify: only UTF-8 and UTF-16 are required to be supported by applications that process NIMAS files. Using another, it is quite possible the file would be corrupted when processed by, for example, a conversion tool or player. This corruption would most likely take the form of special characters (quotes, accented letters, etc.) being rendered incorrectly. More careful applications may refuse to process the file and return an 'unknown encoding' error. There are several free software packages that convert character sets. The DAISY Pipeline also has a '"charset switcher" filter. A program expecting UTF-8 but finding other encoding will definitely render incorrectly if the file has any characters beyond the traditional ASCII range. It seems that using encoding other than UTF-8 (or UTF-16) is not a good idea. While using UTF-8 is not required, it seems it would not be worthwhile to substitute another for it.

5. 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.
  • Embedded text in images should be included as long descriptions or in-line text (see the text in images section for more information).


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:
Folder named 'Sample Folder' with a sub-folder named 'images'

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

Folder named 'U01C01'Folder named 'U99C99' = bodymatter and rearmatter
Naming here provides information about image location to unit and chapter level.

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


An icon that occurs several times in frontmatter and twice per chapter in bodymatter:
Folder named 'Sample Folder' with a sub-folder named 'images' with a sub-folder named 'thruout' that contains an image file named 'studyicon.jpg'

A folder of images occurring in the middle of a work:*
Folder named 'Sample Folder' with a sub-folder named 'images' with sub-folders named 'thruout', 'U00', 'U01C01', and 'U02C08'. The 'U02C08' folder contains image files named 'p212-001.jpg', 'p212-002.jpg', 'p213-001.jpg', and 'p214-001.jpg'.

An image that occurs in the frontmatter of a work:
Folder named 'Sample Folder' with a sub-folder named 'images' with a sub-folder named 'U00' that contains an image file named 'pvii-006.jpg'.

*Note that “U02C08” subsequent to “U01C01” in the second example above illustrates the fact that not all pages/chapters/units of all works will have images.  The example demonstrates a numerical sequence where not every step in a possible sequence is necessary.

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:

An image with this filename appears on page 4 of the original work and is the 2nd 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:
Graphic showing the numeric location of four images on a page

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.

Mark-up for math content—equations, symbols, and the like—should now be created using MathML where feasible. Please see the Images and mark-up of math content section for more information.


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.

6. 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 Opens new windowNIMAC Metadata 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" "">

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:

The major parts of the OEBPS Package file are:
A unique identifier for the OEBPS Publication as a whole.
Publication metadata (title, author, publisher, etc.).
A list of files (documents, images, style sheets, etc.) that make up the publication. The manifest also includes fallback declarations for files of types not supported by this specification.
An arrangement of documents providing a linear reading order.
A set of alternate reading sequences through the publication, such as selective views for various reading purposes, reader expertise levels, etc.
A set of references to fundamental structural features of the publication, such as table of contents, foreword, bibliography, etc.*


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 Opens new window 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 (Opens new window 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"/>
<item id="imgarrow" href="images/U00C00/arrow.svg" media-type="image/svg+xml"/>
<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 (Opens new windowIANA).

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 Opens new windowNIMAC 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.

7. 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.

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.

See the recently created NIMAS Files Best Practices document for specific, practical best practices for creating NIMAS filesets.

Go directly to the OEBPS 1.2 specification at the Opens new window<OeB> Open eBook Forum.

Opens new windowOpening the eBook, by Didier Martin. (2000.)
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.

8. Document updates (2007–present)

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

Changes were made to this document as of May 29, 2008:

  • The NIMAS Fileset, addition

Changes were made to this document as of July 9, 2008:

  • general edits

Changes were made to this document as of October 15, 2008:

  • Best Practices section, separated to the NIMAS Files Best Practices document
  • Preparing images for a NIMAS fileset, addition
  • Creating a NIMAS-conformant XML content file, addition

Changes were made to this document as of May 5, 2009:

  • Preparing images for a NIMAS fileset, addition

Changes were made to this document as of January 6, 2010:

  • Validating a NIMAS-conformant XML content file, addition

Changes were made to this document as of April 29, 2010:

  • Links (URLs), update

Changes were made to this document as of May 5, 2009:

  • Preparing images for a NIMAS fileset section, addition

Changes were made to this document as of June 1, 2010:

  • Character Encoding (UTF-8 and UTF-16), addition

Changes were made to this document as of October 8, 2010:

  • DTD and OPF references, addition

Last Updated: 07/02/2014

ClickSpeak Play Pause Stop