<!-- ============================================================= --> <!-- MODULE: List Element Classes --> <!-- VERSION: 2.3 --> <!-- DATE: February 2007 --> <!-- --> <!-- ============================================================= --> <!-- ============================================================= --> <!-- PUBLIC DOCUMENT TYPE DEFINITION --> <!-- TYPICAL INVOCATION --> <!-- "-//NLM//DTD Archiving and Interchange DTD Suite List Class Elements v2.3 20070202//EN" Delivered as file "list.ent" --> <!-- ============================================================= --> <!-- ============================================================= --> <!-- SYSTEM: Archiving and Interchange DTD Suite --> <!-- --> <!-- PURPOSE: Names all elements in the list class. These are --> <!-- all lists except the lists of bibliographic --> <!-- references (citations). Lists are considered --> <!-- to be composed of items. --> <!-- --> <!-- CONTAINS: 1) Default definition of the list class --> <!-- 2) Definition List attributes --> <!-- 3) Definition Lists <def-list> --> <!-- 4) Ordinary lists (number, bullet, plain) <l> --> <!-- --> <!-- CREATED FOR: --> <!-- Digital archives and publishers who wish to --> <!-- create a custom XML DTD for original markup of --> <!-- journal literature, books, and related material, --> <!-- or for archiving and transferring such material --> <!-- between archives. --> <!-- --> <!-- This DTD is in the public domain. An organization --> <!-- that wishes to create its own DTD from the suite --> <!-- may do so without permission from NLM. --> <!-- --> <!-- The suite has been set up to be extended using a --> <!-- new DTD file and a new DTD-specific customization --> <!-- module to redefine the many Parameter Entities. --> <!-- Do not modify the suite directly or redistribute --> <!-- modified versions of the suite. --> <!-- --> <!-- In the interest of maintaining consistency and --> <!-- clarity for potential users, NLM requests: --> <!-- --> <!-- 1. If you create a DTD from the Archiving and --> <!-- Interchange DTD Suite and intend to stay --> <!-- compatible with the suite, then please include --> <!-- the following statement as a comment in all of --> <!-- your DTD modules: --> <!-- "Created from, and fully compatible with, --> <!-- the Archiving and Interchange DTD Suite." --> <!-- --> <!-- 2. If you alter one or more modules of the suite, --> <!-- then please rename your version and all its --> <!-- modules to avoid any confusion with the --> <!-- original suite. Also, please include the --> <!-- following statement as a comment in all your --> <!-- DTD modules: --> <!-- "Based in part on, but not fully compatible --> <!-- with, the Archiving and Interchange DTD --> <!-- Suite." --> <!-- --> <!-- Suggestions for refinements and enhancements to --> <!-- the DTD suite should be sent in email to: --> <!-- archive-dtd@ncbi.nlm.nih.gov --> <!-- --> <!-- ORIGINAL CREATION DATE: --> <!-- December 2002 --> <!-- --> <!-- CREATED BY: Jeff Beck (NCBI) --> <!-- Deborah Lapeyre (Mulberry Technologies, Inc.) --> <!-- Bruce Rosenblum (Inera Inc.) --> <!-- --> <!-- NLM thanks the Harvard University Libraries, both --> <!-- for proposing that a draft archiving NLM DTD for --> <!-- life sciences journals be extended to accommodate --> <!-- journals in all disciplines and for sponsoring --> <!-- Bruce Rosenblum's collaboration with other DTD --> <!-- authors in completing Version 1.0. The Andrew W. --> <!-- Mellon Foundation provided support for these --> <!-- important contributions. --> <!-- --> <!-- ============================================================= --> <!-- ============================================================= --> <!-- DTD VERSION/CHANGE HISTORY --> <!-- ============================================================= --> <!-- ============================================================= Version Reason/Occasion (who) vx.x (yyyy-mm-dd) ============================================================= Version 2.3 (DAL/BTU) v2.3 (2007-02-02) Enhancement Release (2.3) following the Working Group meetings of Oct-Nov/2006-Jan/2007. No backward-incompatible changes. Archiving loosened even more. New structures for all the DTDs. 13. TERM ELEMENTS - Added <chem-struct-wrapper> to the contents of <term> using -%chem-struct-wrap.class; inside -%term-elements; so that you can use a <chem-struct-wrapper> anywhere you can use a <disp-formula>. 12. NEW PARAMETER ENTITIES - Added parameter entities for the attribute lists of: - def-item - term 11. Updated public identifier to "v2.3 20070202//EN" ============================================================= Version 2.1 (DAL/BTU) v2.1 (2005-06-30) Changed to MathML 2.0 and MathML 2.0 Character Sets Added new material requested by NCBI 10. LIST ITEM ATTRIBUTE - made into a PE, so that individual DTDs could change the attribute "id" from CDATA to type ID. 9. Updated public identifier to "v2.3 20070202" ============================================================= Version 2.0 (DAL/BTU) v2.0 (2004-08-30) Major requirement changes led to the new release, producing DTD version "2.0": a) The splitting of the Archival and Interchange Tag Set DTDs into three DTDs from two: an authoring DTD, an archive regularization and interchange DTD (the current Blue Publishing DTD), and a preservationist archive DTD (the current Green Archiving and Interchange DTD). b) AIT Working Group suggestions from the June 04 meeting and June/July 2004 followup discussions c) Suite remodularization to meet new (and newly articulated) modularization requirements d) New or renamed classes and mixes to make modifications easier and more consistent 8. COMPLETE MODELS WHEN OVER-RIDING A MODEL (for all Parameter Entities suffixed "-model") ### Customization Alert ### Made all the model over-rides consistent. Some included the outer parentheses, some did not. They all do now, as this is the most flexible system, allowing for #PCDATA, mixed, or element content. (This is in direct contrast to the "-element" suffixed models, which are designed to prohibit element content and permit only #PCDATA or mixed content.) - %def-item-model; - %def-list-model; - %list-model; - %list-item-model; 7. PARAMETER ENTITY RENAMING a. ELEMENTS CHANGED TO MODELS ### Customization Alert ### There is a DTD naming convention that PEs which contain full content models are named with a "-model" suffix, in contrast to OR-groups of elements which are added to #PCDATA within a specific content model that are suffixed "-elements". The few Parameter Entities that broke that pattern and were renamed: - %def-item-elements; ==> %def-item-model; - %list-item-elements; ==> %list-item-model; b. RENAME EXISTING CLASSES ### Customization Alert ### Some classes did not have the ".class" suffix. Changed the names to add the class suffix: - %block-math.class; (used in %term-elements;) 6. DEFAULT CLASSES - Were moved from this module to %default-classes.ent; 5. Updated public identifier to "v2.3 20070202" ============================================================= Version 1.1 (TRG) v1.1 (2003-11-01) 4. Added ID attribute to element <def-item>. Rationale: Provide unique identifier so <def-item> element can be linked to. 3. Added element <label> to parameter entities %def-item-elements; and %list-item-elements; (now named %list-item-model;) Rationale: To provide <label> when needed for format over-ride. 2. Added new parameter entity %list-item-elements (now named %list-item-model;) to contain contents of <list-item> Rationale: In order to distinguish between models used by the Archiving DTD and the Publishing DTD, it was necessary to create a parameter entity that could be overridden. 1. Added new parameter entity %def-item-elements to contain contents of <def-item> Rationale: In order to distinguish between models used by the Archiving DTD and the Publishing DTD, it was necessary to create a parameter entity that could be overridden. --> <!-- ============================================================= --> <!-- PARAMETER ENTITY DEPENDENCIES Requires the following parameter entities be defined before calling this module, usually accomplished in the Customization Module for the specific DTD: - %block-math.class; - %simple-display.class; - %simple-phrase; --> <!-- ============================================================= --> <!-- ============================================================= --> <!-- DEFAULT PE FOR ATTRIBUTE LISTS --> <!-- ============================================================= --> <!-- DEFINITION LIST: DEFINITION ITEM ATTRIBUTES--> <!-- Attributes for the <def-item> element --> <!ENTITY % def-item-atts "id ID #IMPLIED" > <!-- DEFAULT DEFINITION LIST ATTRIBUTES --> <!-- Default attribute lists to be used for Definition (2-part) lists --> <!ENTITY % def-list-atts "" > <!-- DEFAULT LIST CLASS ATTRIBUTES --> <!-- Default attribute lists to be used for most of the types of lists. --> <!ENTITY % list-atts "id CDATA #IMPLIED list-type CDATA #IMPLIED prefix-word CDATA #IMPLIED list-content CDATA #IMPLIED" > <!-- DEFAULT LIST ITEM ATTRIBUTES --> <!-- Default attribute for list items --> <!ENTITY % list-item-atts "id CDATA #IMPLIED" > <!-- DEFINITION LIST: TERM ATTRIBUTES --> <!-- Attributes for the <term> element --> <!ENTITY % term-atts "rid IDREFS #IMPLIED id ID #IMPLIED" > <!-- ============================================================= --> <!-- DEFINITION LIST --> <!-- ============================================================= --> <!-- DEFINITION LIST MODEL --> <!-- Content model for the <def-list> element --> <!ENTITY % def-list-model "(label?, title?, term-head?, def-head?, def-item*, def-list*)" > <!-- DEFINITION LIST --> <!ELEMENT def-list %def-list-model; > <!-- id A unique identifier so that the list may be referenced by an <xref> element list-type List prefix types. Type describes the type of prefix character to be used before each list item. While the type list takes any value, suggested types include: order - Ordered list. Prefix character is a number or a letter, depending on style bullet - Unordered list. Prefix character is a bullet, dash, or other symbol simple - Simple or plain list (no prefix character) In a world of perfect style sheets that is all the types that are necessary, all else is determined by nesting and stylesheets. However, some journals like to give authors more control and they provide types like the following: alpha-lower - Ordered list. Prefix character is a lowercase alphabetical character alpha-upper - Ordered list. Prefix character is an uppercase alphabetical character roman-lower - Ordered list. Prefix character is a lowercase roman numeral roman-upper - Ordered list. Prefix character is an uppercase roman numeral prefix-word Holds a word, such as "Step" or "Process" that is to be added to each item of a list. The word is in addition to any prefix characters such as numbers or bullets, and typically follows the prefix character. For example, A list type of "1" and a prefix word of "Step", would produce: "Step 1. aaaa", "Step 2. bbbb", etc. Note that the word is "Step" and not "Step ". The odd man out is the unordered list, type "2", which is the only case in which the prefix character would precede the prefix word: - Step - Step, but the combination is not usually sensible. list-content There are some list models in use in journal DTDs, where a specific named list has been created instead of using <list> or <def-list>. The "list content" attribute should be used to preserve the semantic information concerning such lists types. Potential values include: "procedure", "where-list" (used in equations), "synonymy", "compound-info", "algorithm", "notation", etc. For example, if a list were tagged as <procedure> <list-item>...</list-item> </procedure> that tagging could be preserved as: <list list-content="procedure"> <list-item>...</list-item> </list> --> <!ATTLIST def-list %list-atts; %def-list-atts; > <!-- DEFINITION LIST HEAD ELEMENTS --> <!-- Elements for use in the <def-list> heading elements <term-head> and <def-head>. Design Note: All inline mixes begin with an OR bar, but since %simple-phrase; is an inline mix, the OR bar is already there. --> <!ENTITY % def-list-head-elements "%simple-phrase;" > <!-- DEFINITION LIST: TERM HEAD --> <!-- Title over the first (term) column of a two-part list --> <!ELEMENT term-head (#PCDATA %def-list-head-elements;)* > <!-- DEFINITION LIST: DEFINITION HEAD --> <!-- Title over the second (definition) column of a two-part list --> <!ELEMENT def-head (#PCDATA %def-list-head-elements;)* > <!-- DEFINITION LIST: DEFINITION ITEM MODEL --> <!-- The content model of a <def-item> --> <!ENTITY % def-item-model "(label?, term, def*)" > <!-- DEFINITION LIST: DEFINITION ITEM --> <!-- A term and definition pair inside a definition or two-part list of a two-part list Authoring Note: While this element contains an optional Label element, the Label element should be included only in those circumstances where a formatting override is needed; Label should NOT be used in the ordinary course of tagging. --> <!ELEMENT def-item %def-item-model; > <!-- id Unique identifier so the element may be referenced --> <!ATTLIST def-item %def-item-atts; > <!--ELEM def Defined in %common.ent; --> <!-- DEFINITION LIST: TERM ELEMENTS --> <!-- The elements that can be included along with data characters inside the content model of a <term>. Design Note: All inline mixes begin with an OR bar, but since %simple-phrase; is an inline mix, the OR bar is already there. --> <!ENTITY % term-elements "%simple-phrase; | %block-math.class; | %chem-struct-wrap.class; | %simple-display.class;" > <!-- DEFINITION LIST: TERM --> <!-- The word, phrase, picture, or other noun being defined or description that occupies the first column of a definition or 2-part list and is the subject of the definition or description. --> <!ELEMENT term (#PCDATA %term-elements;)* > <!-- id Unique identifier so the element may be referenced rid Points to the identifier of a definition, so that a term and definition may be linked --> <!ATTLIST term %term-atts; > <!-- ============================================================= --> <!-- LIST ELEMENTS (PARAGRAPH-LEVEL ELEMENTS) --> <!-- ============================================================= --> <!-- LIST MODEL --> <!-- Content model for the <list> element --> <!ENTITY % list-model "(label?, title?, list-item+)" > <!-- LIST --> <!ELEMENT list %list-model; > <!-- id A unique identifier so that the list may be referenced by an <xref> element list-type List prefix types. Type describes the type of prefix character to be used before each list item. While the type list takes any value, suggested types include: order - Ordered list. Prefix character is a number or a letter, depending on style bullet - Unordered list. Prefix character is a bullet, dash, or other symbol simple - Simple or plain list (no prefix character) In a world of perfect style sheets, that is all the types that are necessary, all else is determined by nesting and stylesheets. However, some journals like to give authors more control and they provide types like the following: alpha-lower - Ordered list. Prefix character is a lowercase alphabetical character alpha-upper - Ordered list. Prefix character is an uppercase alphabetical character roman-lower - Ordered list. Prefix character is a lowercase roman numeral roman-upper - Ordered list. Prefix character is an uppercase roman prefix-word Holds a word, such as "Step" or "Process" that is to be added to each item of a list. The word is in addition to any prefix characters such as numbers or bullets, and typically follows the prefix character. For example, a list type of "1" and a prefix word of "Step", would produce: "Step 1. aaaa", "Step 2. bbbb", etc. Note that the word is "Step" and not "Step ". The odd man out is the unordered list, type "2", which is the only case in which the prefix character would precede the prefix word: - Step - Step, but the combination is not usually sensible. list-content There are some list models in use in journal DTDs, where a specific named list has been created instead of using <list> or <def-list>. The "list content" attribute should be used to preserve the semantic information concerning such lists types. Potential values include: "procedure", "where-list" (used in equations), "synonymy", "compound-info", "algorithm", "notation", etc. For example, if a list were tagged as <procedure> <list-item>...</list-item> </procedure> that tagging could be preserved as: <list list-content="procedure"> <list-item>...</list-item> </list> --> <!ATTLIST list %list-atts; > <!-- LIST ITEM ELEMENTS --> <!-- The content model of a <list-item>. --> <!ENTITY % list-item-model "(label?, (%just-para.class; | %list.class;)+ )" > <!-- LIST ITEM --> <!-- Authoring Note: While this element contains an optional Label element, the Label element should be included only in those circumstances where a formatting override is needed; Label should NOT be used in the ordinary course of tagging. --> <!ELEMENT list-item %list-item-model; > <!-- id A unique identifier so that the list item may be referenced by an <xref> element --> <!ATTLIST list-item %list-item-atts; > <!-- ================== End List Class Module ==================== -->