Creating NIMAS Files by 0N4nG1Kh


									                                        Creating NIMAS Files
   1. The NIMAS fileset
   2. Creating a NIMAS-conformant XML content file
         a. well-formed XML documents
         b. valid NIMAS-conformant XML files
         c. DAISY 2005-specific items
         d. best practices
         e. NIMAS 1.1 DTD required attributes
         f. 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
         a. image files
         b. organization of images
         c. value-added components: mark-up of images
         d. value-added components: writing alt text and LDs
         e. images and mark-up of math content
   6. Preparing a package file (OPF)
         a. MIME (Multipurpose Internet Mail Extension)
         b. MIME types
         c. NIMAS filesets and MIME types
         d. NIMAC and metadata
   7. PDF pages

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

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 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
      A good XML document must have a declaration (example: <!DOCTYPE dtbook PUBLIC "-
       //NISO//DTD dtbook 2005-2//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=“”/>)
           o 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

      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>,
      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 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">

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:

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
           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”
(, 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 ANSI/NISO Z39.86) 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 HTML/XHTML/DocBook XML Validator and Transformer online (http://www.xml-, 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> such as, <link
rel="stylesheet" type="text/css" href="filename.css"/>. 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:

Within this parent folder, images should be saved as follows:
            = frontmatter
The zeroes 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.

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:

*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:

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

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

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

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 this 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
         Use Dublin Core (example: <dc:Text>) metadata tags

From the oebps specification publication:

              The major parts of the OEBPS Package file are:

              PACKAGE IDENTITY: A    unique identifier for the OEBPS Publication as a whole.

              METADATA:    Publication metadata (title, author, publisher, etc.).

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

              SPINE: An   arrangement of documents providing a linear reading order.

              TOURS: A set of alternate reading sequences through the publication, such as
              selective views for various reading purposes, reader expertise levels, etc.

              GUIDE:A set of references to fundamental structural features of the
              publication, such as table of contents, foreword, bibliography, etc.3

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 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 ( They are as

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

    _____. OEBPS 1.2 Specification. IDPF,
       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 (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.

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

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.

Go directly to the oebps 1.2 specification at the <OeB> Open eBook Forum.

Opening the eBook, by Didier Martin. (2000.) This article explains the oebps standard using IDPF
content in a more readable style than the spec itself. Note the standard has since been updated from 1.0 to 1.2.

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 August 20, 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 6, 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 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 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


To top