<!--

Title:      BookX Document DTD
Version:    1.0 (preliminary draft, see date)
Date:       28 May 2008  (replaces the DTD dated 01 May 2008)
DTD-URL:    http://bookx.org/dtd/bookx10.dtd
Reference:  (in preparation)
RefURL:     n.a.
Rights:     Copyright 2008 BookX Community. All rights reserved.


Contributors:

     Jon Noring (editor)
     Anthony Pezzuto


BookX Document Template:

     (Includes prolog boilerplate, root and top-level elements (both
     required and optional as noted), and the minimally required
     <bookinfo> elements. Comments in "<!==...==>" MUST be removed.

     The "+-+-+..." lines are themselves NOT part of the template
     and MUST NOT appear in the BookX document ==> they delimite the
     start and end of the template text. Refer to the notes in the
     template for further usage information.)


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE bookx PUBLIC
     "-//BookX//DTD BookX Document 1.0//EN"
     "http://bookx.org/dtd/bookx10.dtd">

<bookx xmlns="http://bookx.org/namespace/BookX/1.0/"
       lang="en-US">

   <bookinfo>

      <booktitle>Required Book Title Goes Here</booktitle>

      <creator role="aut">Required creator name goes here</creator>

      <!== There may be more than one <booktitle> and <creator>, but
           they may not intermix with the other metadata elements;
           order is important.

           For <creator>, the required 'role' attribute value may be
           one from a number of allowed values == "aut", for author,
           is one such allowed value and will be the one most commonly
           used. There are other optional attributes which may be
           added to all the elements in this template.

           More metadata may optionally be added in the <bookinfo>
           section per the allowed content model. ==>

   </bookinfo>

   <frontmatter>  <!== optional frontmatter goes here ==> </frontmatter>

   <bodymatter>   <!== required bodymatter goes here ==> </bodymatter>

   <endmatter>    <!== optional endmatter goes here ==> </endmatter>

</bookx>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Template Usage Notes:

     1. The encoding of the BookX document MUST be either UTF-8 or
        UTF-16. The XML declaration MUST declare this encoding. The
        above example template has been set to 'UTF-8', which is
        highly recommended for all Western languages/character sets.

        (Note that all ASCII encodings conform to UTF-8. ISO-8859
        encodings will also conform to UTF-8 when they encode ONLY
        characters from the ASCII character set.)

     2. The default namespace in the <bookx> element MUST be
        specified, even though declared FIXED in this DTD.

     3. 'lang' is required on <bookx>, and its value MUST conform to
        RFC 3066. It specifies the primary/default language-country
        code of the BookX document content. If some content within the
        document is of a different language-country code than the
        primary language, then such content can and should be marked
        by application of 'lang' to the descendent element containing
        that content.

        The above example template gives the language-country code
        value of 'en-US', which is United States English.

     4. Refer to the comment in the <bookinfo> section.

     5. <frontmatter> and <endmatter> are not required, and if
        present, are not required to contain anything. If they
        are present and empty, they MUST be denoted as:

          <frontmatter></frontmatter>

          <endmatter></endmatter>

        and NOT as <frontmatter/> and <endmatter/>

     6. <bodymatter> is required, and MUST contain at least one
        %Block.class; element. The template above does not include
        any block level elements within <bodymatter>.

     7. All white space and blank lines preceding the <?xml ... ?>
        declaraction must be removed. To be well-formed XML, the
        first characters in the BookX document MUST be "<?xml " (not
        including the optional "byte order mark" for UTF-8/16
        encoding.) Unless XML comments are to be added following the
        closing </bookx>, it is recommended that no white space nor
        blank lines be added after </bookx>.

     8. In the template, be sure to remove the "<== ... ==>" delimited
        comments. Also remove the "+-+-+-..." lines since they are not
        part of the template.



Early Draft Notice:

     This DTD is a very preliminary release. As such it will
     undoubtedly change in many ways, including, but not limited to,
     renaming of elements and attributes, addition and removal of
     elements and attributes, and changing of element content models,

-->

<!-- ENTITIES WITH XHTML DATATYPE NOTATIONS ............ -->

<!NOTATION text
    PUBLIC "-//W3C//NOTATION XHTML Datatype: Text//EN">
<!ENTITY % Text.datatype "CDATA">

<!NOTATION languageCode
    PUBLIC "-//W3C//NOTATION XHTML Datatype: LanguageCode//EN">
<!ENTITY % LanguageCode.datatype "NMTOKEN">
<!-- Language code, as per RFC 3066 -->

<!NOTATION uri
    PUBLIC "-//W3C//NOTATION XHTML Datatype: URI//EN">
<!ENTITY % URI.datatype "CDATA">
<!-- Internationalized Resource Identifiers (see RFC 3987) -->


<!-- ELEMENT ENTITIES .................................. -->

<!ENTITY % Title.class
     "(parttitle | chaptitle | sectitle | subsectitle), subtitle?">


<!ENTITY % Block.class
     "(%Title.class;, epigraph-div?) |
      (p, themebreak?) |
       quote |
       list |
       verse |
       banner |
       letter |
       closer |
       ending |
       imageblock">

<!ENTITY % Inline.class
     "foreign | hi | link | noteref | sub | sup">

<!-- ATTRIBUTE ENTITIES ................................ -->

<!ENTITY % Common.attrib
     "id            ID                       #IMPLIED
      lang          %LanguageCode.datatype;  #IMPLIED
      pubcomment    %Text.datatype;          #IMPLIED
      privcomment   %Text.datatype;          #IMPLIED">

<!-- 'id' attribute applies an identifier to an element. Its value
     MUST be unique in the BookX document. Useful for internal and
     external hypertext linking and association.

     For elements where 'id' is optional, it is strongly recommended
     it be applied, especially for all block-level elements and
     important inline level elements. Doing so provides "hooks"
     allowing for more stable third party links into digital formats
     derived from BookX documents.

     'lang' attribute assigns the language and optional country code
     of the contained content. It is required for the root element
     <bookx>, specifying the primary language and country code of the
     publication. The value of the 'lang' attribute MUST comply with
     RFC 3066:

        RFC 3066:       http://www.ietf.org/rfc/rfc3066.txt
        Language codes: http://www.loc.gov/standards/iso639-2/php/code_list.php
        Country codes:  http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html

     For example, the conforming language-country code for U.S.
     English is "en-US", i.e., lang="en-US".

     The 'pubcomment' and 'privcomment' attributes allow the
     publication author to add an annotation or comment to an element.
     'pubcomment' is similar to the XHTML 'title' attribute, and when
     a BookX document is transformed to XHTML or other vocabulary
     which supports 'title' or its equivalent, the value of 'pubcomment'
     should be preserved. 'privcomment', on the other hand, is intended
     for internal use purposes only for the BookX document, and not for
     any derivatives. Transformation of BookX docs into other XML
     documents MUST NOT preserve/transfer the value of 'privcomment'
     unless the target vocabulary also supports a "private comment"
     attribute.
-->


<!-- CHARACTER ENTITY REFERENCES COMMON SET 1.0 ........ -->

<!ENTITY % BookXCharEnt
     PUBLIC "-//BookX//DTD Character Entities 1.0//EN"
    "http://bookx.org/dtd/ent10.ent">

%BookXCharEnt;

<!-- DEPRECATED == The BookX "Mnemonic" Character Entity References
     Common Set, version 1.0, is usable in BookX documents. It is
     identical to the set supported in XHTML, plus the five predefined
     entity references which all XML processors are required to
     recognize.

     A future version of BookX may drop support for these mnemonic
     entities since full Unicode text editors are becoming the norm,
     and that the common schemas, like XML Schema and RelaxNG Schema
     (the next version of BookX may move from DTD to RelaxNG) do not
     support entities (other than by use of a DTD internal subset,
     which is a kludgy fix.)

     In the case where the BookX document author is using a text
     editor restricted to the ASCII set, the recommendation is to
     represent non-ASCII characters in the Unicode set using 'numeric
     character references' specified in XML 1.0:

        http://www.w3.org/TR/REC-xml/#sec-references
-->


<!-- BLOCK LEVEL ELEMENTS AND ATTRIBUTES ............... -->


<!-- Block Elements Containing Other Block Level Elements .... -->

<!ELEMENT bookx            (bookinfo,
                            frontmatter?,
                            bodymatter,
                            endmatter?)>
<!ATTLIST bookx
      id             ID                       #IMPLIED
      lang           %LanguageCode.datatype;  #REQUIRED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      xmlns          %URI.datatype;           #FIXED 'http://bookx.org/namespace/BookX/1.0/'>

<!-- <bookx> is the root element. The attribute 'lang' is required as
     noted elsewhere in this DTD. 'xmlns' is the namepspace
     declaration. Although "FIXED", the namespace declaration MUST
     explicitly appear in <bookx> == this assures if the DOCTYPE is
     missing, the document will still be recognized as BookX 1.0.

     There is a natural division in the content model for <bookx> with
     the <bookinfo> being book metadata, followed by an optional
     <frontmatter> section, followed by the required <bodymatter>
     section (which contains the main content of the book), followed
     by an optional <endmatter> section.
-->

<!ELEMENT bookinfo         (coverimage*,
                            thumbimage*,
                            booktitle+,
                            creator+,
                            publisher?,
                            imprint?,
                            copyright?,
                            identifier*,
                            description?,
                            (contributor | bookdate | subject)*)>
<!ATTLIST bookinfo         %Common.attrib;>

<!-- <bookinfo> is required and contains the book's metadata/catalog
     information. The contained elements correspond to, although some
     are renamed for, those in the Dublin Core Metadata Element Set,
     as will be noted elsewhere in this DTD:

        http://dublincore.org/documents/dces/

     Inspection of the <bookinfo> content model shows that the order
     of the various metadata/catalog elements is important. This
     assures that for direct rendering of BookX documents, when some
     or all of the metadata fields are to be displayed, they will
     display in the typical order used in book title and copyright
     pages.
-->

<!ELEMENT frontmatter      (epigraph-book?, dedication?)>
<!ATTLIST frontmatter      %Common.attrib;>

<!-- <frontmatter> is optional, and when present may contain one
     <epigraph-book> and/or one <dedication>, in that order of
     appearance. If <frontmatter> is present, it may also remain empty
     and if so, MUST be represented by <frontmatter></frontmatter>.
-->

<!ELEMENT epigraph-book    ((p | quote | verse)+, closer?)>
<!ATTLIST epigraph-book
      %Common.attrib;
      tocitem        (yes|no)                 'no'
      toctitle       %Text.datatype;          #IMPLIED>

<!ELEMENT dedication       (p | quote | verse)+>
<!ATTLIST dedication
      %Common.attrib;
      tocitem        (yes|no)                 'no'
      toctitle       %Text.datatype;          #IMPLIED>

<!-- Both <epigraph-book> and <dedication>, which are optional (and
     each MUST NOT appear more than once), represent special
     "titleless" chapter-level divisions that may appear in the
     <frontmatter> of the book. Usually they are styled differently
     from the rest of the book, thus the need for special recognition
     and placement in the <frontmatter> section. BookX does not
     support "line-type" structures within these divisions other than
     verse.

     (For the definition of an epigraph, refer to the note for the
     <epigraph-div> element.)

     Normally these divisions are not included in a table of contents.
     If the author wishes they be included, then the author MUST do
     all three of the following:

        1. set the 'id' to some document-unique value,
        2. set 'tocitem="yes"' and
        3. include some text for the attribute 'toctitle' which will
           be used to assign the title for the table of contents item.

     If these three requirements are not all met, reading systems are
     not required to include these divisions in a table of contents if
     it builds one.
-->

<!ELEMENT bodymatter       (%Block.class;)+>
<!ATTLIST bodymatter       %Common.attrib;>

<!-- <bodymatter>, which is required, contains the body content of the
     book, except for the special content divisions that may go into
     the optional <frontmatter> and <endmatter> sections. <bodymatter>
     MUST contain at least one %Block.class; element.
-->

<!ELEMENT endmatter        (notes?, glossary?)>
<!ATTLIST endmatter        %Common.attrib;>

<!-- <endmatter> is optional, and when present may contain one
     <notes> section and/or one <gloassary> section, in that order of
     appearance. If <endmatter> is present, it may also remain empty
     and if so, MUST be represented by <endmatter></endmatter>.
-->

<!ELEMENT epigraph-div    ((p | quote | verse)+, closer?)>
<!ATTLIST epigraph-div    %Common.attrib;>

<!-- According to TEI, an epigraph "contains a quotation, anonymous or
     attributed, appearing at the start of a section or chapter, or on
     a title page."

     The "book" type of epigraph applies to the whole book (i.e., it
     is usually placed on the title page) and is applied using
     <epigraph-book> in the <frontmatter> section.

     The "division" type, <epigraph-div>, may be applied to any of the
     BookX-supported divisions (part, chapter, section, subsection,
     etc.) If present, it MUST always appear after the division
     title(s) (which may also include a <subtitle>) and before the
     start of the actual content of the division (the start is
     usually, but not always, a paragraph. (Refer to the special note
     further restricting what is allowed to follow <parttitle>.)
-->

<!ELEMENT quote            (p |
                            quote |
                            list |
                            verse |
                            banner |
                            letter |
                            closer)+>
<!ATTLIST quote            %Common.attrib;>

<!-- note that <quote> is analogous to XHTML <blockquote>, but does
     not have quite as expansive of a content model as its XHTML
     cousin. In BookX, <quote> may not include: any of the division
     titles, themebreaks, endings, nor imageblocks.
-->

<!ELEMENT list             (listitem)+>
<!ATTLIST list
      %Common.attrib;
      marker         (glyph|noglyph|ordered)  'glyph'>

<!-- 'marker' specifies the general class of markers used for the
     list items in the list:

     a) "glyph" (default when 'marker' not specified)

        Reading systems, following CSS and browser practice, should
        default visual presentation of <list marker="glyph"> to
        "disc".

        CSS may be used to change the glyph from the reading system
        default, as the reading system allows.

        XHTML equivalent for <list marker="glyph"> is <ul>.

     b) "noglyph". No glyphs.

        Since XHTML (without CSS) does not support a "no glyph" list
        type, the fallback is to <ul> which will display glyphs. In
        XHTML, CSS 'list-style-type: none' must be applied to remove
        list item glyphs.

     c) "ordered".

        Per reading system defaults and CSS settings, the list items
        will be ordered, either numerically or alphabetically.

        XHTML equivalent for <list marker="ordered"> is <ol>, which,
        in turn, usually defaults to decimal markers for top level
        lists. CSS must be used to fine tune the ordered markers.

        Since <list> may be hierarchically nested in BookX, CSS
        authors may consider setting 'list-style-type' for
        'marker="ordered"' based on hierarchical level. E.g.,
        'decimal' for first level, 'lower-roman' for the second level,
        and 'lower-latin' for the third level.
-->

<!ELEMENT listitem         (p | quote | list | verse)+>
<!ATTLIST listitem         %Common.attrib;>

<!ELEMENT verse            (versetitle?, verseauthor?, stanza)+>
<!ATTLIST verse            %Common.attrib;>

<!-- <verse> is a block of verse, such as part or whole of a poem,
     song lyrics, etc. A verse is divided into one or more <stanza>,
     and each <stanza> contains one or more <verseline>. One
     <versetitle> and/or one <verseauthor> may appear before the first
     stanza.
-->

<!ELEMENT stanza           (verseline)+>
<!ATTLIST stanza           %Common.attrib;>

<!-- <stanza> represents a stanza in a verse block. -->

<!ELEMENT banner           (bannerline)+>
<!ATTLIST banner
      %Common.attrib;
      align-request  (left|center|right)      'center'>

<!-- <banner> is an oft-used device in fiction to show the text on
     a sign or bill, a placard, a newspaper headline, output on a
     computer screen, etc.

     Example of one type of construct which <banner> may represent:

        Mary approached the door. On the door was an embossed sign:

                            Room 24

                        Dr. John H. Doe
                       Internal Medicine

        She slowly opened the door and with dread walked in.

     <banner>, when used, MUST contain one or more <bannerline>.

     The attribute 'align-request" is a request by the author on how
     the lines in <banner> are to be aligned during visual
     presentation. The default is "center". They may also be aligned
     to the 'left' or to the 'right'.

     Refer to the note for <bannerline>, which includes sample markup
     for the above example, and what to do if <banner> is insufficient
     for visually representing the desired construct.
-->

<!ELEMENT letter           (opener,
                            (p | quote | list | verse)+,
                            closer)>
<!ATTLIST letter           %Common.attrib;>

<!-- <letter> represents a letter, memo or similar type of written
     communication, a common device used in fiction. A letter consists
     of an <opener>, which may include one or more <dateline>, and
     <addressblock> (commonly used in business letters) and possibly
     some type of salutation (like "Dear John"), the body of the
     letter, and a <closer>, typically of the form <salute> (e.g.,
     "yours truly,"), <signed>, the signer's <role>, and possibly one
     or more <dateline>.
-->

<!ELEMENT opener           (dateline*,addressblock?,salute?)>
<!ATTLIST opener           %Common.attrib;>

<!-- <opener> is similar to that in TEI, used here to designate an
     opener for <letter>. It MUST only appear within <letter>, unlike
     <closer>, which, besides appearing in <letter>, may also appear
     elsewhere.
-->

<!ELEMENT addressblock     (addressline+)>
<!ATTLIST addressblock     %Common.attrib;>

<!-- <addressblock> contains one or more <addressline>, and may be
     used in <opener> for a recipient address block, often used in
     business letters (but rarely, if ever, used in personal letters.)
-->

<!ELEMENT closer           (salute?, (signed, role?)*, dateline*)>
<!ATTLIST closer           %Common.attrib;>

<!-- <closer> is similar to that used in TEI to designate a closing
     "signature block" or similar, such as for a foreword. It is also
     used within a <letter>.
-->

<!ELEMENT ending           (#PCDATA | foreign | hi | sub | sup)*>
<!ATTLIST ending           %Common.attrib;>

<!-- <ending> is for endings to chapters/sections, or to the book,
     such as for enclosing the ubiquitous "The End". In TEI, the
     closest equivalent element is <trailer>.

     In document structure, <ending> is considered a part of the
     division which the content immediately preceding <ending> belongs
     to, even if the <ending> is used, for example, as the ending to
     the entire book.
-->

<!ELEMENT notes            (notestitle?,
                            notescommentary?,
                            note+)>
<!ATTLIST notes
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      tocitem        (yes|no)                 'yes'
      toctitle       %Text.datatype;          #IMPLIED>

<!-- <notes> is an optional division which may appear only in the
     <endmatter> section. When present, it MUST contain one or more
     notes. It MUST be given an 'id'.

     <notes> may contain a <notestitle> (e.g. "Referenced Notes"), of
     the same structural level and purpose as a <chaptitle>, and MUST
     be rendered when present. <notes> may also contain a
     <notescommentary> (which MUST only appear after <notestitle> when
     <notestitle> is present), which adds an explanation of the note
     or notes which follow. <notescommentary> MUST be rendered when
     present.

     By default (with 'tocitem="yes"'), the <notes> block is to appear
     in a reading system generated table of contents. In this case
     (that is, when 'tocitem' is set to "yes"), if <notestitle> is not
     provided, then a publication author MUST provide a suitable title
     using 'toctitle'. When <notestitle> is provided, and 'toctitle'
     is also assigned, the table of contents MUST use the 'toctitle'
     value, but may also allow the end-user to see the full
     <notestitle>.
-->

<!ELEMENT notestitle       (#PCDATA | %Inline.class;)*>
<!ATTLIST notestitle       %Common.attrib;>

<!-- <notestitle> is an optional chapter-level title for the <notes>
     block. It is intended to be rendered. Unlike the other division
     level title elements, an 'id' is not required since that MUST be
     applied to the parent <notes> element immediately preceding it.

     Refer to the comment for <notes> regarding the table of contents.
-->

<!ELEMENT notescommentary  (p)+>
<!ATTLIST notescommentary  %Common.attrib;>

<!-- <notescommentary>, when present, MUST contain one or more
     paragraphs which provide a brief commentary or explanation of the
     note or notes to follow in the <notes> division block. It is
     intended to be rendered.
-->

<!ELEMENT note             (notemark?, (p | quote | list | verse)+)>
<!ATTLIST note
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED>

<!-- Every note in the <notes> block MUST include an 'id', and MUST
     include at least one of the supported block-level elements.

     However, as noted for the <noteref> element, a <note> does not
     require a corresponding <noteref> in the content. In addition,
     multiple <noteref> may reference the same <note>.
-->

<!ELEMENT glossary         (glossarytitle?,
                            glossarycommentary?,
                            gloss+)>
<!ATTLIST glossary
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      tocitem        (yes|no)                 'yes'
      toctitle       %Text.datatype;          #IMPLIED>

<!-- <glossary> is an optional section block that may appear in the
     <endmatter> section. When present, it MUST contain one or more
     <gloss> (a gloss is a term/definition pair.) <glossary> MUST be
     given an 'id'.

     <glossary> may contain a <glossarytitle> (e.g. "Definition of
     Terms Used In This Book") which is of the same structural level
     and purpose as a <chaptitle>, and MUST be rendered when present.

     <glossary> may also contain an optional <glossarycommentary>
     (which, when present, MUST appear after <glossarytitle> when
     <glossarytitle> is present), which adds an explanation of the
     term/definitions which follow.  <glossarycommentary> MUST be
     rendered when present.

     By default ('tocitem="yes"' is the default), the <glossary> block
     is to appear in a reading system generated table of contents. In
     this case (that is, 'tocitem' is set to "yes"), if <glossarytitle>
     is not provided, then a publication author MUST provide a suitable
     title using 'toctitle'. When <glossarytitle> is provided, and
     'toctitle' is also assigned, the table of contents MUST use the
     'toctitle' value, but may also allow the end-user to see the full
     <glossarytitle>.
-->

<!ELEMENT glossarytitle    (#PCDATA | %Inline.class;)*>
<!ATTLIST glossarytitle    %Common.attrib;>

<!-- <glossarytitle> is an optional chapter-level title for the
     <glossary> block. It is intended to be rendered when present.
     Unlike the other division level title elements, an 'id' is not
     required since that MUST be applied to the parent <glossary>
     element immediately preceding it.
-->

<!ELEMENT glossarycommentary  (p)+>
<!ATTLIST glossarycommentary  %Common.attrib;>

<!-- <glossarycommentary>, when present, MUST contain one or more
     paragraphs which provide a brief commentary or explanation of the
     gloss or glosses in the <glossary> division block. It is intended
     to be rendered when present.
-->

<!ELEMENT gloss            (term, definition)>
<!ATTLIST gloss
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED>

<!-- Every <gloss> in the <glossary> block MUST include an 'id'
     attribute value. However, a <gloss> does not require it to be
     referenced/linked from elsewhere in the publication (use
     <link> for referencing a <gloss> from elsewhere in the BookX
     document.)

     A <gloss> MUST include one <term> and one <definition>, in that
     order. (Similar to the XHTML <dt> and <dd> elements.)
-->

<!ELEMENT term             (#PCDATA | foreign | hi | sub | sup)*>
<!ATTLIST term             %Common.attrib;>

<!-- Every <gloss> MUST have a <term>, which contains only PCDATA and
     optional inline elements.
-->

<!ELEMENT definition       (p |
                            quote |
                            list |
                            verse)+>

<!-- Every <gloss> MUST have a <definition> associated with the
     <term>. <definition> may contain any mix of <p>, <quote>, <list>,
     and <verse>. It MUST NOT itself contain PCDATA.
-->

<!ELEMENT imageblock       (image, caption?)>
<!ATTLIST imageblock
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      position-req   (inflow|
                      ownpage|
                      floatleft|
                      floatright)             'inflow'
      assocwith      (prev|next)              'next'
      loiitem        (yes|no)                 'yes'
      loititle       %Text.datatype;          #REQUIRED>

<!-- <imageblock>, which may appear in the bodymatter, is non-empty
     and its content contains the image and the optional image
     caption.

     The 'position-req' attribute requests the positioning of the
     <imageblock> in the document during visual presentation. Default
     is "inflow":

        a. "inflow": The <imageblock> is kept at the block-level and
           appears in the natural flow of document content == no
           special page breaks before/after the image are requested,
           and the <imageblock> is not to be merged (floated) into
           the content block preceding or following it.

        b. "ownpage": Similar to "inflow", except it is requested that
           when the document is rendered, the <imageblock> is placed
           alone on its own page. For reading systems that cannot place
           the <imageblock> on its own page, "ownpage" defaults to
           "inflow".

        c. "floatleft" and "floatright": Requests that <imageblock>
           is "floated" into the block immediately following the
           <imageblock>, either to the leftside or rightside. This is
           further explained in:

              http://www.w3.org/TR/CSS21/visuren.html#propdef-float

     Note that a reading system that can display images may choose not
     to honor 'position-req' values other than "inflow" for reasons of
     optimal display on the target reading device(s), and may also
     choose the horizontal and vertical alignment of the image block.
     However, the reading system should honor the values of
     'position-req' when it is capable of so doing.

     'assocwith', which has the default value of ("next"), states
     whether the <imageblock> is associated with the block immediately
     preceding it ("prev"), or immediately following it ("next"). The
     purpose of this association is for determining which structural
     level the <imageblock> belongs to when it could be ambiguous ==
     it is only of significance when the block immediately following
     an <imageblock> is a structural division title.

     BookX document authors should not override the default
     'assocwith' value unless the block immediately following
     <imageblock> is a new division title and the <imageblock> is
     associated with the prior content, such as for placing
     <imageblock> at the end of a chapter or other division.

     (Note that a conflict arises when 'position-req' is set to
     "floatright" or "floatleft" and 'assocwith' is set to "prev"
     == one reason the default value of 'assocwith' is "next". If
     this conflict is not resolved, such as by a BookX conformance
     checker, reading systems are to honor the value of
     'assocwith="prev"' and reset the value of 'position-req' to
     "inflow".)

     'loiitem' states whether or not the image item is to appear in
     a reading system generated "List of Illustrations". Default is
     'yes'.

     'loititle' is the required title to use for the List of
     Illustrations as well as being the equivalent to the XHTML 'alt'
     attribute of <img> for accessibility purposes, thus it is always
     required even if 'loiitem' is set to "no". (In addition, the
     publication author should assign a title to 'pubcomment', which
     is equivalent to XHTML 'title' == it can be the same as the
     value applied to 'loititle'. If 'pubcomment' is not present,
     then conversion systems should first add 'pubcomment' and
     assign it the same value as 'loititle'.

     'id' is required for enabling linking in the List of
     Illustrations, as well as for individualized CSS styling.
-->

<!ELEMENT caption          (p | quote | list | verse)+>
<!ATTLIST caption          %Common.attrib;>

<!-- <caption> is optional, containing the caption or legend
     associated with the image within an <imageblock>.
-->


<!-- Block Elements Containing Text And Inline Elements  -->

<!ELEMENT p                (#PCDATA | %Inline.class;)*>
<!ATTLIST p
      %Common.attrib;
      continuation   (yes|no)                 'no'>

<!-- The well-known paragraph.

     To aid in third party linking, it is recommended that all <p> in
     a BookX document be assigned an 'id'.

     The 'continuation' attribute, whose default value is "no", is for
     specifying if the paragraph is or is not a continuation of (or is
     a part of) the last <p> preceding it in the same structural
     hierarchical level.

     This attribute, when explicitly set to the value of "yes", is for
     the rare situation where a paragraph within a structural
     hierarchical division is interrupted by one or more intervening
     non-paragraph block level items, such as <quote>, <verse>,
     <list>, <banner>, <imageblock>, etc.

     This may be important for a variety of reasons, both presentation
     and non-presentation. For example, it may be important in visual
     presentation where for a particular CSS style sheet indentation
     may be used for new paragraphs, but would clearly be
     inappropriate for any continued portion.

     Example:

        <p>Mary gently sung this lullaby:</p>

           <verse>...</verse>

        <p continuation="yes">while she rocked the baby's cradle.</p>

     In this example, we actually have one logical paragraph with an
     intervening block-level <verse> section.

     Note that setting 'continuation' to "yes" MUST NOT be used for
     purposes other than what it is intended for. For example, it
     MUST NOT be used to solely override paragraph settings in a
     particular CSS style sheet.

     As one machine-enforceable test of this requirement, if the
     author sets 'continuation' to "yes", but there is no preceding
     <p> in the same structural hierarchical level (note that
     structural hierarchical levels are defined by the various title
     elements), then BookX conversion and reading systems MUST assume
     the value is "no". BookX conformance checkers MUST flag when this
     particular error situation is encountered.
-->

<!ELEMENT parttitle        (#PCDATA | %Inline.class;)*>
<!ATTLIST parttitle
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      tocitem        (yes|no)                 'yes'
      toctitle       %Text.datatype;          #IMPLIED>

<!ELEMENT chaptitle        (#PCDATA | %Inline.class;)*>
<!ATTLIST chaptitle
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      tocitem        (yes|no)                 'yes'
      toctitle       %Text.datatype;          #IMPLIED>

<!ELEMENT sectitle         (#PCDATA | %Inline.class;)*>
<!ATTLIST sectitle
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      tocitem        (yes|no)                 'yes'
      toctitle       %Text.datatype;          #IMPLIED>

<!ELEMENT subsectitle      (#PCDATA | %Inline.class;)*>
<!ATTLIST subsectitle
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      tocitem        (yes|no)                 'yes'
      toctitle       %Text.datatype;          #IMPLIED>

<!-- There are four levels of titles which may appear in <bodymatter>
     and imply hierarchical structure or divisions. They are
     equivalent to XHTML headers. The order of hierarchy:

        <parttitle>
        <chaptitle>   <!== This is the "top" level ==>
        <sectitle>
        <subsecttitle>

     The main division is <chaptitle>, to be applied to chapters (or
     similar top level major divisions) and other prefatory and
     end-placed <bodymatter> divisions like foreword, introduction,
     conclusion, etc. All books will use <chaptitle> except for those
     where there is only one structural division in the book and that
     division does not have a title other than the book title.

     <parttitle> is a special case, and is used ONLY to bundle
     chapters together (when the author calls for this), and in
     presentation to the reader is often called "Part" or "Book"
     (e.g., "Book One").  <parttitle> is used only when the book
     author has decided to collect chapters together under a common
     header. (However, *importantly* note that sometimes the author
     will call a chapter-level division a "Book" or "Part" without
     bundling any sub-divisions within it, such as <chaptitle>. In
     this case, use <chaptitle>, <sectitle> or ,subsecttitle> (as
     appropriate for its hierarchical level) even if the header titles
     will say "Part" or "Book".)

     Note that if <parttitle> is used, it (and its <subtitle> if used)
     MUST be followed either by a <chaptitle>, or an <epigraph-div>
     followed by a <chaptitle>. That is, here is allowed markup in
     using <parttitle>:

        <parttitle>...</parttitle>

        <subtitle>...</subtitle>  <!== optional ==>

        <epigraph-div>...</epigraph-div>  <!== optional ==>

        <chaptitle>...</chaptitle>  <!== required in this situation ==>

     Since a DTD cannot enforce this requirement, a BookX conformance
     checker needs to check for this requirement.

     <sectitle> and <subsectitle> are finer divisions within
     <chaptitle>. In fiction and similar simpler non-fiction books
     these are only occasionally used (<subsectitle> is only rarely
     used.) Finer divisions are mostly used in scholarly, legal, and
     technical documentation and references, which BookX is not
     intended to markup. (For more complex document types use either
     DocBook or TEI.)

     One <subtitle> may optionally appear immediately following any
     of the four level titles, and is as described: a subtitle. It is
     not a standalone title with a recognized level.

     This specification does not, and cannot, specify how the various
     division title/headers are to be visually displayed, but they
     should be presented in a distinct way so the reader will readily
     recognize what they are.

     Although the defined division title/headers may include the
     inline elements, these inline elements should only be applied
     sparingly for their intended use, and not used solely for
     attempting to override, or substitute for, the visual styling of
     these division title/headers. (Refer to the section detailing
     the <hi> element.)

     The attribute 'tocitem' for the division titles states whether or
     not the division is to appear in a reading system generated table
     of contents. Default is 'yes'.

     The attribute 'toctitle' is the title to use in the table of
     contents; if 'toctitle' is not present, the full content of the
     division title is to be used.

     The attribute 'id' is required for table of contents linking
     purposes and for general third-party linking.
-->

<!ELEMENT subtitle         (#PCDATA | %Inline.class;)*>
<!ATTLIST subtitle         %Common.attrib;>

<!-- The optional <subtitle> may appear once (and only once) after one
     of the division title elements. It provides a subtitle to the
     main title.
-->

<!ELEMENT versetitle       (#PCDATA | %Inline.class;)*>
<!ATTLIST versetitle       %Common.attrib;>

<!ELEMENT verseauthor      (#PCDATA | %Inline.class;)*>
<!ATTLIST verseauthor      %Common.attrib;>

<!-- For info on <versetitle> and <verseauthor>, and the following
     <verseline>, refer to the comment for <verse>.
-->

<!ELEMENT verseline        (#PCDATA | %Inline.class;)*>
<!ATTLIST verseline
      %Common.attrib;
      indent-request (0|1|2|3|4|5|6)          '0'>

<!-- 'indent-request' assigns a requested amount of indentation for
     the verseline when visually presented. Default is '0', meaning no
     indentation with respect to the containing stanza block box.

     This specification does not define the exact amount of visual
     indentation for each integer value, since optimum presentation is
     very much device-dependent. Reading systems are free to define
     the actual amount, if any, of indentation for each non-zero value
     of 'indent-request'.
-->

<!ELEMENT bannerline       (#PCDATA | %Inline.class;)*>
<!ATTLIST bannerline
      %Common.attrib;
      size-request   (large|medium|small)     'medium'>

<!-- The attribute 'size-request' is a request for the relative size
     of the font when the <bannerline> is visually presented. The
     default value is "medium". Reading systems are free to interpret
     the actual values of 'size-request' during visual presentation.

     A blank <bannerline> (e.g. <bannerline></bannerline) is
     significant, and designates a request by the author for a blank
     line "spacer" during visual presentation. 'size-request' may be
     applied to this blank line request as well.

     Using the example given for <banner>, where for visual
     presentation the author requests "Room 24" to be small,
     "Internal Medicine" to be normal size, and "Dr. John H. Doe"
     to be large; to have a large blank line between "Room 24" and
     "Dr. John H. Doe"; and for all the lines to be centered relative
     to each other, the markup would be as follows:

        <banner align-request="center">

           <bannerline size-request="small">Room 24</bannerline>

           <bannerline size-request="large"></bannerline>

           <bannerline size-request="large">Dr. John H. Doe</bannerline>

           <bannerline size-request="normal">Internal Medicine</bannerline>

        </banner>

     For "banners" where the author wants more control over the
     visual presentation, or where the banner is more complex than
     can be handled with <banner> markup, the author should instead
     create an image of the "banner" they want and embed it
     appropriately using <imageblock>.
-->

<!ELEMENT salute           (#PCDATA | %Inline.class;)*>
<!ATTLIST salute           %Common.attrib;>

<!ELEMENT signed           (#PCDATA | %Inline.class;)*>
<!ATTLIST signed           %Common.attrib;>

<!ELEMENT role             (#PCDATA | %Inline.class;)*>
<!ATTLIST role             %Common.attrib;>

<!ELEMENT dateline         (#PCDATA | %Inline.class;)*>
<!ATTLIST dateline         %Common.attrib;>

<!ELEMENT addressline      (#PCDATA | %Inline.class;)*>
<!ATTLIST addressline      %Common.attrib;>

<!-- <salute>, <signed> and <dateline> are similar to those used in
     TEI. <role> is similar to TEI <roleName>.

     <salute> is a salutation of some sort which may be used in
     <opener> and <closer>

     <signed> is the name (full, initialied, etc.) of the signator and
     may be used in the <closer>. If the signator's name is not given
     but only a role/position, then place the role/position into
     <signed> and not into <role> (see next).

     <role> is the role or position of the signator, and may be used
     in the <closer>. It may only appear after a <signed>.

     <dateline> designates a date, place and/or setting, and may be
     used in <opener> and <closer>.

     <addressline> is a line of the "recipient information" often used
     in the opener of business letters. Used only in <addressblock>
     which may only appear in <opener>
-->

<!ELEMENT notemark         (#PCDATA | foreign | sub | sup)*>
<!ATTLIST notemark         %Common.attrib;>

<!-- Refer to the comments elsewhere in this DTD regarding notes. -->


<!-- ************************************************************ -->

<!-- The <bookinfo> block level elements for metadata/catalog
     information. Some are required == see the <bookinfo> content
     model and associated comment which specifies the order the
     metadata MUST appear. These metadata elements map to Dublin Core
     Metadata Elements as noted.

     Most of these <bookinfo> block elements allow certain inline
     elements to be applied. However, note that conversion and
     reading systems may ignore these inline elements (but not the
     textual content they contain) as they deem appropriate or
     necessary. BookX authors should avoid using, or only minimally
     use, these inline elements (with the exception of <foreign> whose
     use is always encouraged.)
-->

<!ELEMENT bookdate         (#PCDATA)*>
<!ATTLIST bookdate
      %Common.attrib;
      event          (available |
                      created |
                      issued |
                      modified)               #REQUIRED>

<!-- <bookdate> designates the date/time for an important event in the
     life-cycle of the book, such as the publishing date. There may be
     any number of <bookdate> elements to cover multiple events.
     Equivalent to Dublin Core 'date'.

     Since the content value of <bookdate> is strictly defined as
     follows, no inline elements are to appear, only PCDATA.

     The character data expressing the date/time of the event MUST
     conform to the W3C Note Date and Time Formats. For example, a
     full date (with no time) MUST be of the form YYYY-MM-DD (e.g.,
     "2006-05-29"). See:

        http://www.w3.org/TR/NOTE-datetime

     The required attribute 'event' assigns a name to the event. The
     set of values come from the Dublin Core Terms, and MUST be one
     of the following four values:

        available
        created
        issued    (i.e., published)
        modified

     See:  http://dublincore.org/documents/dcmi-terms/
-->

<!ELEMENT booktitle        (#PCDATA | foreign | hi | sub | sup)*>
<!ATTLIST booktitle        %Common.attrib;>

<!-- <booktitle>, which is required, includes the title of the book.
     There may be more than one line to a book title (e.g. a title/
     subtitle), so multiple <booktitle> are used, which MUST be
     sequential == and ORDER IS IMPORTANT. It is equivalent to Dublin
     Core 'title'.
-->

<!ELEMENT contributor      (#PCDATA | foreign)*>
<!ATTLIST contributor
      %Common.attrib;
      role           NMTOKEN                  #REQUIRED
      file-as        %Text.datatype;          #IMPLIED>

<!-- <contributor>, the name of a person or entity who contributed to
     the production of the book, but not at the level of a <creator>.
     Equivalent to Dublin Core 'contributor'. See note for <creator>
     for more information, including the supported attributes.
-->

<!ELEMENT copyright        (#PCDATA | foreign | hi | sub | sup)*>
<!ATTLIST copyright        %Common.attrib;>

<!-- <copyright> includes information about the various rights, not
     limited only to copyright, held in and over the book. Equivalent
     to Dublin core 'rights'.
-->

<!ELEMENT coverimage         EMPTY>
<!ATTLIST coverimage
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      imagefile      %URI.datatype;           #REQUIRED
      platform       %Text.datatype;          #IMPLIED>

<!ELEMENT thumbimage         EMPTY>
<!ATTLIST thumbimage
      id             ID                       #REQUIRED
      lang           %LanguageCode.datatype;  #IMPLIED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED
      imagefile      %URI.datatype;           #REQUIRED
      platform       %Text.datatype;          #IMPLIED>

<!-- The optional <coverimage> and <thumbimage> elements are used to
     assign book "cover" and "thumb" images, respectively, to the
     BookX publication. They are considered metadata, and thus placed
     in the <bookinfo> section. When present, they MUST be placed
     before the required <booktitle>.

     Even though considered metadata, BookX reading systems may use
     these images for content presentation purposes. In addition, an
     optionally generated "List of Illustrations" (described elsewhere
     in this specification) may include a link to a cover image (but
     not thumb) rendition.

     The difference between "cover" and "thumb" is somewhat arbitrary,
     with "cover" essentially being a detailed, higher-resolution
     image meant to be viewed as an important part of the book
     content, while "thumb" is used for low-resolution thumbnail and
     icon images, usually for purposes outside of the actual book
     content.

     If a thumb image is included with the BookX publication, a cover
     image should also be included.

     If a cover image is included but no thumb image, a BookX reading
     system may generate a thumb image from the cover image.

     Note that in the content model for <bookinfo>, all <thumbimage>,
     when present, must appear after all <coverimage> when they are
     present.

     For brevity, only <coverimage> will be described from here on,
     but the comments equally apply to <thumbimage> except where
     otherwise noted.

     There may be more than one <coverimage>. Order is important, with
     the first one being the preferred, "primary" image to be used by
     BookX reading systems, the second one the next preferred, and so
     on.

     The following recommendations are made for the primary
     <coverimage>:

        a) the primary cover image should not be tied to any
           particular platform,

        b) the primary cover image should be a lossless PNG of
           sufficiently high resolution so a particular BookX reading
           system may resample the image (size and/or color depth) for
           optimal presentation, and

        c) the 'platform' attribute should not be used with the
           primary <coverimage>.

     The optional attribute 'platform' may be used to specify that
     the cover image has been optimized for a specific BookX reading
     system platform or purpose (however, other platforms may
     certainly consider using the image.) When the 'platform'
     attribute does not appear, it is assumed the image is not
     platform-specific. This specification does not define nor approve
     any particular set of values for the 'platform' attribute.

     Each <coverimage> MUST include an 'id'.

     The cover image file is specified using the required 'imagefile'
     attribute (refer to the <image> element discussion for details on
     the 'imagefile' attribute value.)
    
     Although optional, the 'pubcomment' attribute should be included
     to provide a detailed cover image description for accessibility
     purposes.
-->

<!ELEMENT creator          (#PCDATA | foreign)*>
<!ATTLIST creator
      %Common.attrib;
      role           NMTOKEN                  #REQUIRED
      file-as        %Text.datatype;          #IMPLIED>

<!-- The elements <creator> (at least one required) and <contributor>
     (optional) designate the name of a person or entity responsible
     for some recognized role in the process to author the content of
     the Publication. <creator> is used for those who played a primary
     or major role, while <contributor> is used for those who played a
     secondary, supporting or minor role.

     To illustrate the difference, those whose names are intended to
     appear on a title page are creators, while all others are
     contributors.

     A book may have multiple creators and contributors, and an
     individual or entity can have multiple roles.

     If there is more than one <creator>, the order is considered
     important, with the first being the most important when there
     are differences in importance. (For multiple <contributor>,
     though, order is not significant.)

     In the event the <creator> for the book is not known or cannot
     be given, for the content use some descriptor like "Unknown",
     "Anonymous", etc.

     <creator> is equivalent to Dublin Core 'creator'.

     Both elements, <creator> and <contributor>, support the same
     attributes in addition to the Common attributes:

     'role':    (required) a role value which MUST be drawn from the
                list of the three character MARC Relator codes at:

                   http://www.loc.gov/marc/relators/relaterm.html

                Examples of the more common MARC Relator codes:

                   role="aut"   (for an author, the most common role)
                   role="ill"   (for an illustrator)
                   role="trl"   (for a translator)

     'file-as': (optional) used to specify a normalized form of the
                character data, suitable for machine processing, such
                as for sorting by a person's last name.

     Example:

        <creator role="aut" file-as="Doe, John Henry">John Doe</creator>
-->

<!ELEMENT description      (#PCDATA | foreign | hi | link | sub | sup)*>
<!ATTLIST description      %Common.attrib;>

<!-- <description> is a single paragraph description or account of the
     book, useful for marketing, cataloging, etc. Equivalent to Dublin
     Core 'description'.
-->

<!ELEMENT identifier       (#PCDATA)*>
<!ATTLIST identifier
      %Common.attrib;
      version        (1|2|3|4|5|6|7|8|9|10)   #REQUIRED>

<!-- <identifier>, which is optional but HIGHLY RECOMMENDED, contains
     an identifier to the BookX version of the book. The identifier
     value MUST conform with the requirements, and should conform to
     the recommendations, given in Section 3.2 of the GCF 1.0 spec.
     For the latest version of the GCF spec, refer to the directory:

        http://www.windspun.com/gcf/

     Although this specification does not specify the namespaces from
     which the identifier MUST be drawn, when there is no need for an
     identifier from a formal registration authority (like ISBN), it
     is STRONGLY RECOMMENDED it be a UUID. UUIDs are free, for all
     practical purposes globally unique, and easily generated using
     free online services (there are even registration services), as
     well as free, downloadable generators. When using a UUID as an
     identifier, the syntax of its use, meeting the requirements as
     noted above, is demonstrated in the example below.

     There may be more than one identifier, with the first being
     considered the "primary" identifier.

     Note that the contents of <identifier> may only contain PCDATA,
     and no inline elements.

     The required 'version' specifies the version number (starting
     with '1' == minor changes to the book should increment the
     version number keeping the ID the same.) The attribute value MUST
     conform to the requirements, and should conform to the
     recommendations, given in section 4.3.4 of the OpenReader Binder
     1.0 spec:

          http://www.openreader.org/spec/bnd10.html#sec4.3.4

     Example:

        <identifier version="1">urn:uuid:6a2014b0-87a2-11da-a72b-0800200c9a66</identifier>

     <identifier> is equivalent to Dublin Core 'identifier'.
-->

<!ELEMENT imprint          (#PCDATA | foreign)*>
<!ATTLIST imprint          %Common.attrib;>

<!-- See note for <publisher>. Mappable to Dublin Core 'publisher' -->

<!ELEMENT publisher        (#PCDATA | foreign)*>
<!ATTLIST publisher        %Common.attrib;>

<!-- <publisher>, and the related <imprint>, designates the entity
     responsible for making the resource available. <imprint> is
     usually a marketing "arm" for a publisher. Both are equivalent
     to Dublin core 'publisher', which unfortunately does not
     distinguish between a publisher and a publisher's imprint.
-->

<!ELEMENT subject          (#PCDATA | foreign | sub | sup)*>
<!ATTLIST subject
      %Common.attrib;
      scheme         %Text.datatype;          #REQUIRED>

<!-- <subject>, which is optional, may occur any number of times to
     apply multiple subjects. The content designates the subject or
     topic keywords for the book. Equivalent to Dublin Core 'subject',
     which says the following about 'subject':

        "Typically, Subject will be expressed as keywords, key phrases
        or classification codes that describe a topic of the resource.
        Recommended best practice is to select a value from a
        controlled vocabulary or formal classification scheme."

     The required 'scheme' attribute designates the scheme for the
     associated subject. It is recommended the scheme be a published
     standard maintained by an established organization.

     If the subject is drawn from either the Library of Congress
     Subject Headings, or is a Library of Congress Control Number, the
     value of 'scheme' should be 'lcsh' or 'lcc', respectively.

     Examples:

        <subject scheme="lcsh">Nebraska-+-Fiction.</subject>

        <subject scheme="lcc">PS3505.A87</subject>

        <subject scheme="My Own Scheme!">Fiction:Nebraska</subject>
-->

<!-- Note that most of the above <bookinfo> elements may contain the
     inline elements for direct rendering purposes, such as for
     generating title and/or copyright pages. However, translation
     by conversion/reading systems of this metadata into other formats
     may require stripping away the inline elements leaving the bare
     text. BookX publication authors should make sure the text, sans
     any inline elements, is reasonably acceptable for usage. For
     example, subscripted and superscripted characters will translate
     to default non-offset characters.
-->

<!-- Block Elements Which Are Empty .................... -->

<!ELEMENT image            EMPTY>
<!ATTLIST image
      %Common.attrib;
      imagefile      %URI.datatype;           #REQUIRED
      linktarget     %URI.datatype;           #IMPLIED>

<!-- 'imagefile' references the image resource by its URI/IRI, which
     MUST be of PNG, JPEG or GIF media type. It is recommended that
     an image referenced by 'imagefile' be local to, and bundled with,
     the BookX document, and not to include a pathname.

     When a PNG image, the filename suffix should be ".png".  When
     JPEG, the filename suffix should be ".jpg" or ".jpeg". When GIF,
     the filename suffix should be ".gif".

     This specification strongly recommends that for lossless images,
     PNG be used instead of GIF.

     'linktarget' may be used to add a hypertext link to the image
     (since <image>, being empty, cannot contain <link>.) The
     attribute value of 'linktarget' is the URI/IRI target of the
     hypertext link, which may either be internal or external to the
     BookX document. An internal link MUST be by fragment identifier,
     targeting any element which includes an 'id'. A 'linktarget' in
     <image> may include a <note> (while a 'linktarget' in <link>
     MUST not target a <note> since that is the role of <noteref>.)

     (Note: SVG, JPEG 2000, and other media types (including
     multimedia) may be supported in the future. Also, a future
     version of this specification may add an attribute specifying the
     MIME media type of the image resource object.)
-->

<!ELEMENT themebreak       EMPTY>
<!ATTLIST themebreak
      %Common.attrib;
      dingbat-image  %URI.datatype;           #IMPLIED>

<!-- <themebreak> inserts a theme or story gap/break between
     paragraphs in the same division. In visual presentation, such a
     break is either shown as extra space between the paragraphs, or
     includes a dingbat. CSS may be used to insert the extra space or
     embed a dingbat graphic.

     The optional attribute 'dingbat-image' allows the BookX author
     to specify a supplied dingbat image for visual reading systems to
     optionally use for the themebreak. The rules for dingbat image
     media type and filenaming follow that for <image>. A visual
     reading system is not required to use the author-supplied
     dingbat; alternative CSS style sheets for presentation may also
     substitute their own dingbat, or use none at all. In addition, a
     visual reading system may align the dingbat as it sees fit; for
     consistency, the dingbat supplied by the BookX author should
     minimize white space on all sides of the image, and reading
     systems should assume such white space minimization.

     Another important requirement is that <themebreak> MUST not be
     inserted for purposes other than designating a theme/story break
     within a section.

     Because of potential misuse of this element (similar to how <br>
     is grossly misused in HTML), <themebreak> MUST ONLY occur after a
     <p> and before another <p>. Unfortunately, because of the
     limitations of DTD-based content models, this DTD enforces that
     <themebreak> may only occur after <p>; conformance checkers MUST
     also check to see if every occurence of <themebreak> is directly
     followed by another <p> with the value of its 'continuation'
     attribute being "no" ("no" is the default for <p>.)

     (If a BookX author wants to end each division with a dingbat
     image, use <imageblock> since a divsion ending is not a theme
     break.)

     This strict requirement may be relaxed at a future time if there
     is deemed to be a need for such relaxation.

     (As another check against misuse of <themebreak>, the BookX author
     must realize that some third-party CSS style sheets will insert a
     dingbat at <themebreak>. So if the BookX author is misusing
     <themebreak>, such as to force "white space" in various places
     for visual presentation and not to flag an actual theme/story
     break, a dingbat will be placed in unwanted positions for certain
     visual presentations. In addition, note that text-to-speech
     systems will also interpret <themebreak> to denote an actual
     story/theme break and that will be reflected in the vocal
     presentation. This is an important philosophy of BookX: markup
     structure and semantics, not presentation, and trust the reading
     systems and alternate CSS style sheets, including those supplied
     by the BookX authors, will present it properly. BookX is strictly
     designed to this philosophy == the 'visual-request' attribute for
     <hi> is the only departure, and even this is quite restricted as
     noted in the discussion about the use of this attribute.)
-->


<!-- INLINE LEVEL ELEMENTS ............................. -->

<!-- The inline elements apply specific semantics to chunks of
     text within block level elements.
-->


<!-- The "Highlighting" Inline Element ................. -->

<!ELEMENT hi               (#PCDATA |
                            foreign |
                            link |
                            noteref |
                            sub |
                            sup)*>
<!ATTLIST hi
      %Common.attrib;
      type           (computer-text |
                      distinct |
                      foreign |
                      name |
                      other |
                      quote |
                      title |
                      vocal-stress-mild |
                      vocal-stress-strong |
                      word-as-word)           #REQUIRED
      visual-request NMTOKENS                 #IMPLIED>

<!-- <hi> is an inline element for specifying that the contained
     content is highlighted. That is, the highlighted text is somehow
     distinct from the surrounding text in the containing text block.

     Since presentation can be so varied (many flavors of visual,
     audio, and tactile), the BookX approach is to apply, as much as
     possible, semantic rather than presentational meaning to the
     highlighted text to give presentation systems greater flexibility
     in how to optimally render (visually, aurally or tactilly) to the
     reader. In addition, the semantic approach makes the text more
     useful for a variety of non-presentational purposes.

     Simply marking up a chunk of text as "italic" or "bold" is
     clearly useless for non-visual types of presentation, such as
     text-to-speech and Braille. It is also too forceful, demanding
     a particular presentation on all visual reading systems,
     including reading systems that may not even have an italic font.

     But with semantic meaning, the presentation system can optimally
     present the content to the user in the most understandable and
     aesthetically-pleasing way, and allows for seamlessly applying
     multiple style sheets.

     <hi> MUST include a 'type' attribute whose value defines the
     highlighting semantics == why the content is highlighted ==
     important for a variety of reasons which benefit BookX document
     authors, readers, and applications (not discussed here.)

     The value of 'type' MUST be one of the following (listed in
     alphabetical order, not in order of importance or predicted
     occurence in BookX documents):

        computer-text
        distinct
        foreign
        name
        other
        quote
        title
        vocal-stress-mild
        vocal-stress-strong
        word-as-word

     Detailed explanation of the allowed 'type' values, again in
     alphabetical order:

     1) type="computer-text"

        Computer-related text, such as input, output, variables, and
        code. This spec makes no distinction between these uses since
        BookX is not intended for technical publications where
        differentiation of these uses is important.

        Recommended default visual presentation is MONOSPACE font.

     2) type="distinct"

        A good overview description of "distinct" is from TEI P4
        (section 6.3.2.3) http://www.tei-c.org/P4X/CO.html#COHQHD :

           "Identifies any word or phrase which is regarded as
           linguistically distinct, for example as archaic, technical,
           dialectal, non-preferred, etc., or as forming part of a
           sublanguage."

        In essence, a sort of "special language" for a particular
        group of people.

        If the content is a formal, recognized language, such as
        English, French, Latin, German, etc., use type="foreign"
        instead.

        Recommended default visual presentation is ITALIC.

     3) type="foreign"

        The content is to be highlighted because it is a formal
        foreign language, such as English, French, German, Latin, etc.
        When this type value is assigned, the 'lang' common attribute
        MUST also be used to identify the language.

        Recommended default visual presentation is ITALIC.

        For assigning the language of text which is NOT to be
        highlighted, use the <foreign> element.

     4) type="name"

        The content is a name/title of some sort (usually a proper
        noun), applied to a specific person, object (including classes
        of objects), era, event, etc.

        (However, for names or titles of creative works, use "title".)

        One of the more well-known purposes is for marking up the name
        of a ship, e.g. <hi type="name">Titanic</hi>.

        Recommended default visual rendering is ITALIC.

     5) type="other"

        Use this value ONLY when:

          a) none of the other 'type' values even approximately apply
             to the content,

             AND

          b) the content is NOT to be vocally stressed in
             text-to-speech.

        Recommended default visual presentation is ITALIC.

     6) type="quote"

        The content is an inline quote intended to be visually
        emphasized.

        Recommended default visual presentation is ITALIC.

     7) type="title"

        The content is a name or title applied to a particular
        creative work, such as a book, magazine, newspaper, movie,
        play, article, song, poem, opera, symphony, painting,
        sculpture, etc.

        (For a name/title for anything other than a creative work, use
        "name" instead.)

        BookX does not specify a particular style guide (such as the
        "Chicago Manual of Style") to use for deciding when a creative
        work title is to be highlighted, or simply enclosed in quotes.
        (For example, Chicago Manual of Style recommends major
        creative works be highlighted in italic, while more minor
        works, like song titles and newspaper/magazine articles, be
        put in quotes.)

        Recommended default visual presentation is ITALIC.

     8) type="vocal-stress-mild"
     9) type="vocal-stress-strong"

        The content is emphasized for rhetorical, linguistic or
        literary effect, either in the author's voice, or by some
        other person/character that the author is quoting.

        As one important test, if such content is to be voiced, such
        as reading out loud or generated by a text-to-speech engine,
        it would be voiced with obvious vocal emphasis or inflection.
        For example:

           "You can't do <hi type="vocal-stress-mild">that</hi>!"

        The difference between "vocal-stress-mild" and
        "vocal-stress-strong" is the degree of the rhetorical/literary
        stress or emphasis.

        The recommended default visual presentation of
        "vocal-stress-mild" is ITALIC.

        The recommended default visual presentation of
        "vocal-stress-strong" is BOLD.

        The "vocal-stress-*" 'type' values MUST NOT be used as a
        "catch-all" for text highlighting/emphasis == these elements
        should only be used for the specific purpose just described.

        However, note that when the author intends the content to be
        vocally emphasized even if the highlighted content is best
        described with another 'type' value (not including "other"),
        use the desired "vocal-stress-*" value. This assures
        text-to-speech engines will properly emphasize the content.

        For certain situations, the author may be tempted to use
        "vocal-stress-strong" to force bold highlighting on visually
        presented inline text for purposes other than strong
        rhetorical/linguistic stress. This is NOT ALLOWED. For
        requesting bold presentation of non-stressed highlighted
        content, use:

           <hi type="..." visual-request="bolder">some text</hi>

     10) type="word-as-word"

         Content is a word or phrase used as a word.

         The approximate TEI equivalent is <mentioned>:

            http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COHQQ

         Example of "word-as-word":

           <p><hi type="word-as-word">Animals</hi> is a common word
           used to describe the species in the
           <hi type="name">Animalia</hi> kingdom.</p>

         Recommended default visual presentation is ITALIC.


     IMPORTANT SUMMARY NOTES in the use of the 'type' values:

     1) It is important that BookX document authors not use the value
        "other"' except when none of the other 'type' values
        describes, even approximately, the semantics (purpose, reason)
        for the highlighting.

     2) When the highlighted content is intended to be vocally
        emphasized (such as in text-to-speech presentation), use
        "vocal-stress-mild" and "vocal-stress-strong" even if
        the highlighted content can be described with another
        'type' value (not including "other"). The reason is to
        communicate to text-to-speech engines that the content is
        to be vocally inflected.

     3) DO NOT USE 'type="vocal-stress-strong" to force bold visual
        presentation when the highlighted content is not to be
        vocally stressed in a strong manner. Instead, apply the
        'visual-request' attribute to the correct highlighting type
        as previously described.

     ***

     The <hi> attribute 'visual-request', short for "visual
     highlighting request", may be applied to the <hi> element. This
     is a REQUEST by the BookX document author that the contained
     content should be visually rendered as specified by the
     attribute value.

     If the reading system honors the request in whole or in part,
     which it NEED NOT honor, it MUST apply the requested style(s) to
     the default style defined by the containing block level element,
     and NOT to adjust the default style already applied to the
     particular <hi type="[whatever]"> when 'visual-request' is not
     present. This distinction is important to minimize styling
     ambiguities == this puts BookX authors, third-party CSS authors,
     and reading system developers on the same page and assures
     reliable and intended visual presentation.

     To reiterate, BookX visual reading systems, and third-party CSS
     style sheets, are NOT REQUIRED to honor 'visual-request', either
     in whole or in part. (And note that for non-visual presentation,
     such as for text-to-speech for use by the blind, visual
     highlighting request is pretty much meaningless.)

     For example, specifying 'font-red' makes no sense for displays
     which cannot display color! And, certain reading systems may not
     be able to fulfill other types of font-related visual styling.

     It is strongly recommended 'visual-request' NOT BE USED except
     for the most unusual and controlled circumstances. And if it is
     used, the publication author should assure the semantics of the
     text is understandable to the reader even when 'visual-request'
     is not recognized/honored, and this includes for text-to-speech
     purposes.

     The 'visual-request' attribute value MUST be a space separated
     list of one or more of the following pre-defined values (CASE IS
     IMPORTANT). Values other than the following MUST be ignored by
     all BookX conversion and reading systems.

     bcolor-aqua    | bcolor-black  | bcolor-blue   | bcolor-fuchsia |
     bcolor-gray    | bcolor-green  | bcolor-lime   | bcolor-maroon  |
     bcolor-navy    | bcolor-olive  | bcolor-orange | bcolor-purple  |
     bcolor-red     | bcolor-silver | bcolor-teal   | bcolor-white   |
     bcolor-yellow  | bolder        | cursive       | fantasy        |
     fcolor-aqua    | fcolor-black  | fcolor-blue   | fcolor-fuchsia |
     fcolor-gray    | fcolor-green  | fcolor-lime   | fcolor-maroon  |
     fcolor-navy    | fcolor-olive  | fcolor-orange | fcolor-purple  |
     fcolor-red     | fcolor-silver | fcolor-teal   | fcolor-white   |
     fcolor-yellow  | italic        | larger        | line-through   |
     monospace      | sans-serif    | serif         | small-caps     |
     smaller        | underline     |

     Note that the above list is derived from the following CSS
     properties:

     background-color (17 colors)
     color            (17 colors)    <!== this is "font" color ==>
     font-family      (serif, sans-serif, cursive, fantasy, monospace)
     font-size        (larger, smaller)
     font-style       (italic)
     font-variant     (small-caps)
     font-weight      (bolder)
     text-decoration  (underline, line-through)

     The 17 font and background color values (prefixed with "fcolor-"
     and "bcolor-", respectively), are defined at:

        http://www.w3.org/TR/CSS21/syndata.html#value-def-color

     This spec does not, and cannot practically-speaking, specify how
     reading systems will apply the values when two or more values
     from the same CSS property appear in the same 'visual-request'
     list, so publication authors should avoid doing this as it will
     lead to unpredictable results. BookX conformance checkers MUST
     explicitly flag this error condition.

     For example, each of the following have ambiguous and competing
     'visual-request' values and should obviously be avoided:

        <hi type="foreign" visual-request="larger smaller">some text</hi>

        <hi type="foreign" visual-request="fcolor-red fcolor-blue">some text</hi>
-->


<!-- Miscellaneous Inline Elements ..................... -->

<!ELEMENT foreign          (#PCDATA)*>
<!ATTLIST foreign
      id             ID                       #IMPLIED
      lang           %LanguageCode.datatype;  #REQUIRED
      pubcomment     %Text.datatype;          #IMPLIED
      privcomment    %Text.datatype;          #IMPLIED>

<!-- BookX recommends that all content in a BookX document be
     assigned a language code. This is done using the 'lang'
     attribute applied to the containing element. Note that this
     specification already requires 'lang' be applied to the root
     element <bookx> to assure that, globally speaking, the default
     language of the BookX document is assigned.

     For content of a different language which otherwise will not be
     marked up using any of the other elements given in this DTD,
     and which will not be highlighted during visual presentation,
     BookX supports the <foreign> element whose sole purpose is to
     apply 'lang' to the contained textual content.

     The content in <foreign> MUST NOT be highlighted during
     presentation.

     If the BookX document author wants certain foreign text to
     be highlighted _because_ it is foreign, then they must use
     the <hi> element as follows:

        <hi type="foreign" lang="...">some text of a different language</hi>
-->

<!ELEMENT link             (#PCDATA | foreign | sub | sup)*>
<!ATTLIST link
      %Common.attrib;
      linktarget     %URI.datatype;           #REQUIRED
      hidden-request (yes|no)                 'no'>

<!-- <link>, which is inline, adds a hypertext link to a word or
     phrase.

     The required attribute 'linktarget' assigns the target URI/IRI
     of the hypertext link. The target may be either internal or
     external. When internal, it MUST be in fragment identifier form
     (e.g., ' linktarget="#para123" '), and may link to any element
     with an 'id' EXCEPT <note>. Only <noteref> and <image> may link
     to <note>.

     The attribute 'hidden-request' requests that during presentation
     the link is not highlighted as a link by the reading system. The
     default is "no", meaning "not hidden".

     For those who design CSS style sheets for displaying BookX and
     various BookX-derived XHTML documents, the <link> element may
     appear within <hi>, and this needs to be considered when the
     hypertext link is not to be hidden (the default).
-->

<!ELEMENT noteref          (#PCDATA | foreign | sub | sup)*>
<!ATTLIST noteref
      %Common.attrib;
      notetarget     %URI.datatype;           #REQUIRED>

<!-- Used to enclose the mark, symbol or number in the main body of
     the text pointing to the same mark, symbol or number in
     <notemark> within some <note>.

     The required 'notetarget' MUST reference the 'id' of a <note> in
     <notes>. However, a <note> does not require there be an
     associated <noteref>. (Note that multiple <noteref> pointing to
     the same <note> is allowed.)
-->

<!ELEMENT sub              (#PCDATA | foreign)*>
<!ATTLIST sub              %Common.attrib;>

<!ELEMENT sup              (#PCDATA | foreign)*>
<!ATTLIST sup              %Common.attrib;>

<!-- Superscript and subscript similar to the same named elements in
     XHTML.

     Although most experts will deem <sub> and <sup> to be a form of
     highlighting, in BookX they are not considered highlighting but
     rather an "addendum" to the Unicode character set. A sort of
     murky distinction that is pretty much academic and irrelevant to
     the BookX author who just wants to get the job done.

     The BookX author must understand that some BookX conversion and
     reading systems may not be able to preserve/handle/present
     superscript and subscript text, and so will ignore any <sub> and
     <sup> markup. For example, "H<sub>2</sub>O" may become "H2O".
     There are several superscripted and subscripted Unicode
     characters that the BookX author may consider using, but these
     are limited in scope to specific characters and some reading
     systems may not provide the necessary glyph for those characters.
     E.g., in Unicode there is support for the character "subscript 2"
     (U+2082), so the just noted example could be written as:
     "H&#x2082;O", or that character encoded at the bit level in an
     UTF-8 or UTF-16 document.
-->

