<?xml version="1.0" ?>
<!-- ***********************
	 ***** article.dtd *****
	 ***********************
		
	An XML document type definition	for use with scientific and scholarly
	articles intended for publication both in print and on line.
	
	This DTD requires the presence of biblist.dtd, which contains definitions
	of numerous elements and entities used below.
		
	Conforms to http://www.w3.org/TR/1998/REC-xml-19980210 		(XML 1.0)
	and is also compliant with SGML systems with an appropriate SGML
	declaration file.
		
	Version R.1.3  (1999-01-15)
		
	Copyright 1999 David Ephron and Openly Informatics, Inc.
	All rights reserved.
	Created by David Ephron and Eric Hellman.
		
	Refer to this file as "http://nj.oclc.org/dtd/article-R.1.3.dtd"
	or as PUBLIC "+//IDN www.openly.com//DTD article-R.1.3//EN//XML" 		
	

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

    Redistributions of source  must retain the above copyright
    notice, this list of conditions and the following disclaimer. 

    Redistributions in binary form must reproduce the above copyright
    notice, this list of conditions and the following disclaimer in
    the documentation and/or other materials provided with the
    distribution.

    The names of the authors may not be used to endorse or promote
    products derived from this specification without specific prior written
    permission. 

    "eFirst XML" is a Service Mark of Openly Informatics, Inc. The eFirst
    name and logo may not be used to endorse or promote
    products derived from this specification without specific prior written
    permission of Openly Informatics, Inc.. 

THIS DOCUMENT TYPE DEFINITION IS PROVIDED ''AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 


	-->
	
<!-- *********************
	 *****  Changes  *****
	 *********************
		
Version R.1.1  (1999-01-06) ESH
	* added compoundFigure element to group related figures and to allow  
	  references to figure 1 when only figure 1a and figure 1b exist.																			Version R.1.2  (1999-01-09) ESH
	* added br to content model of styledEq.																			Version R.1.3  (1999-01-15) ESH
	* dataFile is now allowed to be empty. fileSize attribute added to 
      dataFile.																			-->																	  

<!-- *********************
	 ***** Standards *****
	 *********************
		
	The values of the attribute 'xml:lang' should conform to ISO639
		(e.g. en=English, fr=French, de=German, etc.)
	The values of the attribute 'dateStamp' should conform to
		http://www.w3.org/TR/NOTE-datetime-970915 (yyyy-mm-ddThh:mm:ssZ)
		(e.g. 1998, 1998-09, 1998-09-19, 1998-09-19T14Z, 1998-09-19T14:00:00Z)
	The contents of the element <math> should conform to the specification
		for MathML at http://www.w3.org/TR/REC-MathML
	The values of the attribute 'type', where indicated to be MIME strings,
		should conform to RFC 2045-2049 and the registered MIME types thereof
																			-->																	  
<!-- *********************** -->
<!-- ***** biblist.dtd ***** -->
<!-- *********************** -->

<!-- This DTD makes use of definitions and entities declared in: -->

<!ENTITY % biblist PUBLIC "+//IDN www.openly.com//DTD biblist-B.1.0//EN//XML" "biblist.dtd" >
%biblist;

<!-- ************************* -->
<!-- ***** Text elements ***** -->
<!-- ************************* -->

<!ENTITY % simpInline "#PCDATA | b | i | u | o | sub | sup | ss | tt | small |
					   big | math | propInlinEq | noteRef | xRef | hlink |
					   a | lang | defn | anchor" >
<!ENTITY % compInline "%simpInline; | inlineGraphic | inlinEq | bib" >
<!ENTITY % textElems "%compInline; | preformat | bq | list | dispEq | numEq |
					  br" >

<!-- These three parameter entities describe a hierarchy of permitted text elements found commonly in elements. %simpInline is intended to be safe for use in titles, headings, and so on. -->

<!-- Markup using the elements mentioned above should not introduce any extra whitespace around the opening and closing tags. Do not use line breaks to make the markup of these elements look attractive. Extra whitespace may be preserved in some contexts. -->

<!-- ********************************* -->
<!-- ***** Highest level element ***** -->
<!-- ********************************* -->

<!ELEMENT article (front, (body, back)?) >
<!ATTLIST article id ID #IMPLIED
				  type (paper | abstract | letter | review | comment | reply | 
						informal | news | editorial | otherType) "paper"
				  otherName CDATA #IMPLIED
				  dtdVer CDATA #IMPLIED
				  xml:lang NMTOKEN "en" >

<!-- The 'dtdVer' attribute should contain a url that specifies the version of the DTD in use when a document is created, modified, or checked. The correct url is indicated at the top of this DTD. The xml:lang attribute is assumed to be inherited, unless modified in a child element. -->

<!-- ****************************************** -->
<!-- ***** Elements that comprise article ***** -->
<!-- ****************************************** -->

<!ELEMENT front (docMeta*, docCiteAs?, docCitePP?, cpyrt?, title, subtitle*,
				 authors, history*, erratum*, abstract*, docIndex*) >
<!ELEMENT body ((p | figure | compoundFigure | table | sidebar | adorn)*, 
               section*) >
<!ELEMENT back (ack?, appendices?, notes?, bibliography?, figures?, tables?,
				supMatl?, bibSources?) >

<!-- **************************************** -->
<!-- ***** Elements that comprise front ***** -->
<!-- **************************************** -->

<!ELEMENT docMeta (meta | link)* >
<!ATTLIST docMeta id ID #IMPLIED  >
<!ELEMENT docCiteAs (#PCDATA) >
<!ELEMENT docCitePP (#PCDATA) >
<!ELEMENT cpyrt (#PCDATA) >
<!ELEMENT title (%simpInline;)* >
<!ELEMENT subtitle (%simpInline;)* >
<!ELEMENT history (date) >
<!ATTLIST history id ID #IMPLIED
				  event (received | revised | accepted | erratum) #REQUIRED
				  comment CDATA #IMPLIED >
<!ELEMENT erratum (#PCDATA) >
<!ATTLIST erratum id ID #IMPLIED
				  dateStamp NMTOKEN #IMPLIED
				  comment CDATA #IMPLIED >
<!ELEMENT abstract (p | adorn)* >
<!ATTLIST abstract id ID #IMPLIED
				   xml:lang NMTOKEN #IMPLIED >
<!ELEMENT docIndex (meta)* >
<!ATTLIST docIndex id ID #IMPLIED
				   label CDATA #IMPLIED >

<!-- <docMeta> is a container for metadata that describe the article as a whole. Different <docMeta> elements can be used to group related <meta> elements together. The attribute 'xmlns' can label these sets; for an explanation of how to use this attribute, see the description of the <meta> element in biblist.dtd. Typically, one <docMeta> element will hold Dublin Core metadata and be labeled xmlns = "http://purl.oclc.org/metadata/dublin_core/" and another with xmlns = "http://nj.oclc.org/resources/docid/" will hold internal unique identification information, such as the publisher's internal document ID or SICI. <docCiteAs> is a plain text representation of the preferred citation for the article; this element is a convenience for rendering articles out of the context of an entire issue or volume. <docCitePP> is similar but holds the starting page number only. <cpyrt> is a plain text representation of the desired copyright notice. (The information contained in the preceding two elements will also typically be represented formally somewhere in <docMeta>.) <history> elements should appear in chronological order. <erratum> elements hold descriptions of changes that have been made to the text since publication. <docIndex> elements hold groups of related indexing terms or keys. The attribute 'xmlns' functions as in <meta> while 'label' should indicate the text to precede the indexing terms, such as "PACS" or "Keywords" while the child <meta> elements would each hold one PACS number, one keyword, etc.  -->
				 
<!ELEMENT authors (auth | corpAuth | aff)* >
<!ATTLIST authors model (numbered | grouped) "numbered" >
<!ELEMENT auth (pn, xRef*, authNote*) >
<!ATTLIST auth id ID #IMPLIED
			   comment CDATA #IMPLIED
			   xml:lang NMTOKEN #IMPLIED >
<!ELEMENT corpAuth (orgName, xRef*, authNote*) >
<!ATTLIST corpAuth id ID #IMPLIED
				   comment CDATA #IMPLIED
				   xml:lang NMTOKEN #IMPLIED >
<!ELEMENT authNote (#PCDATA | br)* >
<!ELEMENT aff (meta*, ((orgName, orgAddr?) | orgAddr)) >
<!ATTLIST aff id ID #IMPLIED
			  num CDATA "auto" >

<!-- The <authors> element contains information both about authors and their affiliations. The <auth> element corresponds to an individual author. The <corpAuth> element corresponds to an organization, group, or named collaboration that collectively appears as a single author. The <aff> element corresponds to a single distinct affiliation, such as a university, a department or program within a university, or a corporate laboratory. If multiple authors share a single affiliation, then only one <aff> element describing that affiliation should appear. Every <auth> and <corpAuth> element should ordinarily have one or more child <xRef> elements that point to <aff> elements. This is the method by which authors are correctly associated with affiliations. A single <auth> or <corpAuth> may validly have <xRef>s to multiple <aff> elements, and each <aff> should be the target of at least one <xRef> in an <auth> or <corpAuth>. To distinguish between different departments in a university, treat them as distinct affiliations and associate professors with as many affiliations as is appropriate. Use <authNote>s sparingly only to indicate a permanent institution if different from the listed affiliation or other exceptional information.

Author elements (<auth> and <corpAuth>) should appear within the <authors> container in their intended order of precedence. <aff> elements may validly appear anywhere within the <authors> element. For record keeping purposes, the only association between an author element an an affiliation is through the <xRef> mechanism; order of appearance is irrelevant. For rendering purposes, the placement of the <aff> elements within the <authors> container _is_ relevant. Rendering apps must display the <auth>, <corpAuth>, and <aff> elements in the order in which they appear. Consecutive <auth> and <corpAuth> elements will appear on a single line separated by commas. <aff> elements will always begin on a new line. If the attribute model="numbered", then the rendered will insert appropriate superscript numerals following every name and preceding every affiliation. (In this case, all the authors should appear first followed by all of the affiliations.) If model="grouped" then the numerals will be omitted. (In this case, all the authors associated with one affiliation appear, followed by that affiliation, and so on. This style is only possible for a subset of all cases.) Thus, a pre-processing application must inspect the author list and <xRef> elements, determine which representation is appopriate, set the 'model' attribute, and move the <aff> elements into their correct positions within the <authors> container. Use <br> to indicate natural line breaks in addresses; these will typically be represented as ", " in single line representations. If the attribute num = "auto" then the renderer will number or letter the affiliations consecutively; otherwise, the value of 'num' will be used. The use of manual and automatic numbering must not be mixed. -->

<!-- *************************************** -->
<!-- ***** Elements that comprise body ***** -->
<!-- *************************************** -->

<!ELEMENT p (%textElems;)* > <!-- a basic paragraph -->
<!ATTLIST p id ID #IMPLIED
			indent (default | forcedYes | forcedNo) "default"
			comment CDATA #IMPLIED
			xml:lang NMTOKEN #IMPLIED >
<!ELEMENT section (heading, ((p | figure | compoundFigure | table | sidebar | 
				   adorn)*, section*)) >
<!ATTLIST section id ID #IMPLIED
				  num CDATA "auto"
				  comment CDATA #IMPLIED
				  xml:lang NMTOKEN #IMPLIED >
<!ELEMENT sidebar (heading?, (p | figure | compoundFigure | table | adorn)*) >
<!ATTLIST sidebar id ID #IMPLIED
				  num CDATA "auto" >
<!ELEMENT heading (%simpInline;)* >

<!-- In <p>, 'indent' should normally remain set to "default", which will indent all paragraphs except the first in a section. If a <section> has attribute num="auto" then auto-numbering is used, otherwise the value of the attribute is used; num="none" yields an unnumbered section. "auto" should not be used after a non-auto value, since the number chosen is unpredictable. -->

<!ELEMENT adorn (%simpInline;)* >
<!ATTLIST adorn class NMTOKEN #IMPLIED
				comment CDATA #IMPLIED
				xml:lang NMTOKEN #IMPLIED >


<!-- *************************************** -->
<!-- ***** Elements that comprise back ***** -->
<!-- *************************************** -->

<!ELEMENT ack (p | adorn)* >
<!ELEMENT appendices (section)* >
<!ELEMENT notes (note)* >
<!ELEMENT note (p)* >
<!ATTLIST note id ID #IMPLIED
               num CDATA "auto"
               series (default | alt1 | alt2 | alt3) "default" >

<!-- <ack> is for author acknowledgments. <notes> holds the footnotes and/or endnotes. A <note> can represent an endnote or a footnote and will usually contain one or more <bib>s inline. The determination of note position will not be made in general until render time. The 'series' attribute allows for the separation of multiple series of notes; for example, it may be desireable in some applications to distinguish bibliographic, explanatory, and editorial notes. These might ultimately be rendered together as one series of notes, or perhaps separated as endnotes, numbered footnotes, and starred footnotes, etc. <note>s must be sorted into their correct order for rendering applications. If num = "auto" then the <note>s are automatically numbered consecutively in the order in which they appear in <notes>. Otherwise the value of the attribute is used; the use of automatic and mnual numbering must not be mixed. -->

<!ELEMENT bibliography (heading | bib)* >
<!ELEMENT figures (figure | compoundFigure)* >
<!ELEMENT tables (table)* >
<!ELEMENT supMatl (slides?, dataFile*, (section, notes?)?) >
<!--change in 1.3: dataFile may be empty. fileSize attribute added.-->
<!ELEMENT dataFile (caption?, dataStream?) >
<!ATTLIST dataFile id ID #IMPLIED
				   num CDATA "auto"
				   type (text) "text"
				   file CDATA #IMPLIED
				   fileSize NMTOKEN #IMPLIED
				   path CDATA #IMPLIED >
<!ELEMENT dataStream (#PCDATA) >
<!ATTLIST dataStream xml:space (default | preserve) "preserve" >
<!ELEMENT slides EMPTY >
<!ATTLIST slides type CDATA #IMPLIED
				 count NMTOKEN #IMPLIED
				 file CDATA #IMPLIED
				 path CDATA #IMPLIED >

<!-- <bibliography> contains a (usually alphabetized) bibliography if necessary. A particular <figure> or <table> element may validly appear either at the end in the <figures> and <tables> containers or in between paragraphs in the main text (but not more than once). Processing applications may move a <figure> or <table> element between the main text and the containers in the back in order to specify the location of the anchor point for the object. <supMatl> may optionally contain slides used in a talk accompanying the presentation of the paper, a section (which may contain sub-sections) containing additional text, <figure>s, or <table>s, associated <notes>, or <dataFile>s with raw tab-delimted data. The 'type' of <slides> should be indicated with a MIME string (e.g. "application/pdf" or "application/vnd.ms-powerpoint"). -->

<!-- ******************************* -->
<!-- ***** Block text elements ***** -->
<!-- ******************************* -->

<!ELEMENT preformat (#PCDATA) >
<!ATTLIST preformat xml:space (default | preserve) "preserve" >
<!ELEMENT list (heading?, item+) >
<!ATTLIST list id ID #IMPLIED
			   type (1 | I | i | A | a | circle | square | dash) "circle" >
<!ELEMENT item (p)+ >
<!ATTLIST item num CDATA "auto" >
<!ELEMENT bq (%compInline; | dispEq)* >
<!ATTLIST bq id ID #IMPLIED
			 indent (forcedYes | forcedNo) "forcedNo"
			 xml:lang NMTOKEN #IMPLIED >
			 
<!-- <preformat> preserves line breaks and whitespace and is rendered in a monospace font in a separate text block. <list>s must be supported to three levels of nesting, but need not be supported further. The num attribute behaves as in <note>. To create blockquotes consisting of multiple paragraphs, use consecutive <bq> elements within a single <p>. Restrictions on block text elements to insure proper formatting: the first paragraph of an <item> should not be empty and should not start with a <preformat>, <bq>, <list>, <dispEq>, or <numEq> element. -->

<!-- ******************************** -->
<!-- ***** Inline text elements ***** -->
<!-- ******************************** -->

<!ELEMENT b (%simpInline;)* >
<!ELEMENT i (%simpInline;)* >
<!ELEMENT u (%simpInline;)* >
<!ELEMENT o (%simpInline;)* >
<!ELEMENT sub (%simpInline;)* >
<!ELEMENT sup (%simpInline;)* >
<!ELEMENT small (%simpInline;)* >
<!ELEMENT big (%simpInline;)* >
<!ELEMENT ss (%simpInline;)* >
<!ELEMENT tt (%simpInline;)* >
<!ELEMENT lang (%simpInline;)* >
<!ATTLIST lang xml:lang NMTOKEN #IMPLIED >
<!ELEMENT defn (%simpInline;)* >
<!ATTLIST defn id ID #IMPLIED
			   abbrev NMTOKEN #IMPLIED >

<!-- <b>, <i>, <u>, <o>, <sub>, <sup> represent bold, italic, underline, overline, subscript, and superscript. Double application of these elements has no further effect. To achieve double bold, double subscript or superscript, or superscript directly over subscript, use the <math> element. <small> and <big> decrease/increase the font size by two points and may be nested with effect up to three levels deep. <ss> specifies a sans serif font and <tt> specifies a monospace font. <lang> may be used to mark foreign words in text. <defn> marks the definition of an acronym. The attribute 'abbrev' holds the acronym itself. Rendering applications may search for occurrences of 'abbrev' in the text and link them back to the definition. -->

<!-- ****************************** -->
<!-- ***** Graphical elements ***** -->
<!-- ****************************** -->

<!ELEMENT figure (img, imgAlt*, imgLive*, caption?) >
<!ATTLIST figure id ID #IMPLIED
				 num CDATA "auto"
				 pgWide (0 | 1) "0"
				 filestem CDATA #IMPLIED
				 comment CDATA #IMPLIED >
<!ELEMENT compoundFigure (figure*) >
<!ATTLIST compoundFigure id ID #IMPLIED
				         num CDATA "auto"
			             comment CDATA #IMPLIED >
<!-- added in 1.1. This element groups related figures together, e.g.
figure 1a and figure 1b. and allows xRefs to figure 1 -->
<!ELEMENT table ((htmlTable | preformat | img), imgAlt*, caption?) >
<!ATTLIST table id ID #IMPLIED
				num CDATA "auto"
				cols NMTOKEN "1"
				colWidths CDATA #IMPLIED
				pgWide (0 | 1) "0"
				filestem CDATA #IMPLIED
				comment CDATA #IMPLIED >
<!ELEMENT caption (p | adorn)* >

<!-- <img> and <imgAlt> allow for multiple versions of the same graphical element. The reason for distinguishing between these two element types is that processing applications may thereby designate one representation as primary for use by subsequent rendering applications. <imgLive> can hold a video clip, audio stream, java applet, or other interactive file, but every <figure> must also have a static representation. In <table>, 'cols', 'colWidths', and 'pgWide' are for use by rendering applications. 'filestem' is the filename omitting the type suffix. -->

<!ELEMENT inlineGraphic (img?, imgAlt*) >
<!ATTLIST inlineGraphic id ID #IMPLIED
						filestem CDATA #IMPLIED
						comment CDATA #IMPLIED >
<!ENTITY % graphic.a "id ID #IMPLIED
					  file CDATA #IMPLIED
					  href CDATA #IMPLIED
					  type NMTOKEN #IMPLIED
					  index NMTOKEN #IMPLIED
					  blOffset NMTOKEN #IMPLIED
					  dispSize CDATA #IMPLIED
					  sizeX NMTOKEN #IMPLIED
					  sizeY NMTOKEN #IMPLIED
					  width CDATA #IMPLIED
					  height CDATA #IMPLIED
					  dpi NMTOKEN #IMPLIED
					  xSpace NMTOKEN '0'
					  fileSize NMTOKEN #IMPLIED
					  kind (vector | raster | unknown) 'unknown'
					  origin (original | processed | edited) 'original'
					  sizeChange (none | scale | resolution) 'none'
					  contentChange (preserved | retouched | corrected)
							'preserved'
					  comment CDATA #IMPLIED
					  alt CDATA 'Graphic'" >
<!ELEMENT img EMPTY >
<!ATTLIST img %graphic.a; >
<!ELEMENT imgAlt EMPTY >
<!ATTLIST imgAlt %graphic.a; >
<!ELEMENT imgLive EMPTY >
<!ATTLIST imgLive %graphic.a; >

<!--	In <img> and <imgAlt>, 'type' should use these values:
			gif		Graphics Interchange Format (Compuserve)
			jpg		JPEG
			png		Portable Network Graphics
			eps		Encapsulated PostScript (generic)
			epsf	EPS (Macintosh)
			epsi	EPS (Interchange)
			ps		PostScript
			pict	Macintosh PICT
			wmf		Windows MetaFile
			emf		Enhanced MetaFile
			cgm		Computer Graphics Metafile
			wpg		Word Perfect Graphics
			bmp		Windows Bitmap
			tif		TIFF
			frmi	FrameImage
			frmv	FrameVector
			cdr		CorelDraw
			gem		GEM Metafile
			pdf		Portable Document Format
		
		In <imgLive>, 'type' should use a recognized MIME type, such as
			"video/quicktime", "application/x-java", etc.
		
		index: item number for multi-part files such as pdf or ps page nums
		blOffset: number of points above the baseline to place the graphic
		impSize: scratch for scaling information for rendering apps
		sizeX, sizeY, dpi, units: dimensions of the graphic in the file
		xpace: whitespace to leave on both the left and right (in points)
		fileSize: in kilobytes
		origin: original = as submitted by author, processed = automatically
			converted or altered, edited = manually processed
		sizeChange: scale = the size of the image has been changed, but the
			resolution remains the same; resolution = the pixel density has
			been changed
		contentChange: retouched = minor problems have been corrected,
			corrected = substantial changes have been made
		altLabel: text for HTML img alt tags.                       -->

<!-- ************************* -->
<!-- ***** Math elements ***** -->
<!-- ************************* -->

<!ENTITY % eq.a "id ID #IMPLIED
				 tex CDATA #IMPLIED
				 mt CDATA #IMPLIED
				 filestem CDATA #IMPLIED
				 comment CDATA #IMPLIED" >

<!ELEMENT propInlinEq ((math | styledEq), imgAlt*) >
<!ATTLIST propInlinEq %eq.a; >						
<!ELEMENT inlinEq ((math | styledEq)?, img?, imgAlt*) >
<!ATTLIST inlinEq %eq.a; >
<!ELEMENT dispEq ((math | styledEq)?, img?, imgAlt*) >
<!ATTLIST dispEq %eq.a; >
<!ELEMENT numEq ((math | styledEq)?, img?, imgAlt*) >
<!ATTLIST numEq %eq.a;
				num CDATA "auto" >
<!ELEMENT styledEq (%htmlText; | inlineGraphic | br)* >

<!-- <propInlinEq> must have a non-graphical representation so that it is safe for use in titles, headings, etc. <math> is reserved for MathML data. The attribute 'tex' holds a LaTeX representation of the equation (the less than sign and quote characters must be escaped). The attribute 'mt' holds MathType's internal representation of the equation. -->

<!-- **************************************************************** -->
<!-- ***** Cross reference, linking, and bibliogrpahic elements ***** -->
<!-- **************************************************************** -->

<!ELEMENT noteRef EMPTY>
<!ATTLIST noteRef id ID #IMPLIED
			   	  target IDREF #REQUIRED
			   	  text CDATA #IMPLIED >
<!ELEMENT xRef EMPTY >
<!ATTLIST xRef id ID #IMPLIED
			   target IDREF #REQUIRED
			   type (figure | table | numEq | section | appendix |
			   		 aff | dataFile | sidebar | tn | p) #IMPLIED
			   text CDATA #IMPLIED >
<!ELEMENT hlink (%compInline;)* >
<!ATTLIST hlink id ID #IMPLIED
				target IDREF #REQUIRED >
<!ELEMENT a (%compInline; | meta)* >
<!ATTLIST a id ID #IMPLIED
			href CDATA #REQUIRED
			role CDATA #IMPLIED
			text CDATA #IMPLIED
			dateStamp NMTOKEN #IMPLIED
			xml:link CDATA #FIXED "simple" >
<!ELEMENT anchor (%compInline; | meta)* >
<!ATTLIST anchor id ID #IMPLIED >

<!-- <noteRef> points to a <note> element. A rendering application may assume that the <note>s have been appropriately ordered. <xRef> points to the enumerated types and renders as "Figure 1", "Table 1", "Eq (1)", etc. where the number comes implicitly or explicitly from the referenced object. Whitespace should be left around the <xRef> element if necessary (in general for all types except "aff" and "tn"). The attribute 'text' in <noteRef> and <xRef> is reserved for scratch use by processing apps. <hlink> points to any element internal to the document with an 'id' attribute, and is included to allow for arbitrary hyperlinked text. <a> permits links to external objects with provision for additional attributes in the future for link management; the element content of <a> should be a description of the resource or empty if only the address itself is to be displayed; the address resides exclusively in 'href'. <anchor> provides an arbitrary reference point in the text for use as the target of an <hlink> and also permits the association of a <meta> tag with arbitrary text. -->

<!-- ************************************ -->
<!-- ***** HTML style table support ***** -->
<!-- ************************************ -->

<!ELEMENT htmlTable (tr)+ >
<!ELEMENT tr (th | td)+ >
<!ATTLIST tr align (left | center | right | implied) "implied"
			 valign (top | middle | bottom) "middle" >
<!ELEMENT th (%compInline; | br | tn)* >
<!ATTLIST th align (left | center | right | implied) "implied"
			 rowspan NMTOKEN "1"
			 colspan NMTOKEN "1"
			 width NMTOKEN #IMPLIED >
<!ELEMENT td (%compInline; | br | tn)* >
<!ATTLIST td align (left | center | right | implied) "implied"
			 rowspan NMTOKEN "1"
			 colspan NMTOKEN "1"
			 width NMTOKEN #IMPLIED >
<!ELEMENT tn (%compInline;)* >
<!ATTLIST tn id ID #IMPLIED
			 num CDATA "auto" >

<!-- Basic HTML table support. If align = "implied" in <th> or <td>, then <tr> determines the alignment; if align = "implied" in <tr>, then <th> defaults to "center" and <td> to "left". "rowspan" and "colspan" may not equal 0 (as they may in HTML 4.0). <tn> is a tablenote (a footnote below the table). -->