<!--    Astronomical Dataset Markup Language Document Type 
	Definition DTD - syntax = XML
	dataset DTD  - Version 0.5.1
	This is the Document Type Definition for the data and
	metadata at the Astronomical Data Center at NASA/GSFC.
	Within each document is the metadata for a dataset
	and all of the associated tables, descriptions, and history.
	This document description is the result of long hard work
	on the part of the workers at the ADC.  All questions should
	be addressed to 
        Ed Shaya, Chief Scientist NASA/Raytheon ITSS.
	edward.j.shaya.1@gsfc.nasa.gov
     ==============
	Changes
    ================
April 17, 2000 - email and phone are part of author now, and not address
               - privateCom added to reference. Removed FAX.
               - removed para/warning.
April 6, 2000 - Add dataset/footnotes to hold all referenced footnotes.
              -  Allow for more than one institution per author.
              - Added status="inPreparation" to journal.
              - volume and pagenumber are now optional.
              - added footnoteIdRef to footnote.
Feb. 22, 2000 - XDF version 0.13 replaces tablehead
Jan. 19, 2000 - Major rearrangement of reference.  Now,
 		//references[@type="source"]/reference/title
                                                      /author
                                                      /journal/name
                                                              /volume
 								etc.
               - Replaced super with values.
Dec. 18, 1999  - keywords contains keyword* which are xlink:type=document.
	       - keywords[@list] is now keywords[@parentListURL].
               - altname no longer in astroObjects, instead have name*.
-->
<!NOTATION ps SYSTEM "ghostview" >
<!NOTATION pdf SYSTEM "acroread" >
<!--
     =================================================
        ENTITIES  
     ================================================= -->

<!-- Xlink Entities -->
<!ENTITY % locator.att
   "xmlns:xlink         CDATA	#FIXED 'http://www.w3.org/XML/XLink/0.9'
    xlink:href          CDATA               #REQUIRED" >
<!ENTITY % link-semantics.att
  "xlink:type  (simple|extended|locator|arc) 'simple'" >
<!ENTITY % simple-link-semantics.att
   "xlink:type  (simple|extended|locator|arc) #FIXED 'simple'" >
<!ENTITY % extended-link-semantics.att
   "xlink:type  (simple|extended|locator|arc) #FIXED 'extended'" >
<!ENTITY % remote-resource-semantics.att
  "xlink:role          CDATA               #IMPLIED
   xlink:title         CDATA               #IMPLIED
   xlink:show          (new|parsed|replace) 'replace'
   xlink:actuate       (auto|user)          'user'" >
<!ENTITY % local-resource-semantics.att
   "xlink:content-role  CDATA               #IMPLIED
    xlink:content-title CDATA               #IMPLIED" >

<!-- positive or negative int  -->
<!ENTITY % integer "CDATA" >        

<!ENTITY % astroTerms SYSTEM "http://tarantella.gsfc.nasa.gov/xml/entities/astroTerms.ent" >
		%astroTerms;

<!-- End Entities -->

<!-- The root element is dataset.   Its attribute subject specifies 
		the field of science for this dataset  -->
<!ELEMENT dataset (title, altname*, references, references?, keywords*, 
	descriptions, astroObjects?, tables?, images?, spectra?, 
	textFile*, footnotes?, history, identifier) >
  <!ATTLIST dataset
  xmlns:xlink CDATA   #FIXED  "http://www.w3.org/XML/XLink/0.9"
  subject     CDATA        "astronomy" >

<!-- dataset/title is the full title of the dataset. The partNumber is
   the part number as in part 3 of 4 and links are made to the other
   parts of the series using a pull down menu. -->

<!ELEMENT title (#PCDATA | partNumber | footnote)* >
<!-- PartNumber will have numeric value, plus there should be an extended link document that
links to all of the other parts of the  multipart series.
-->
<!ELEMENT partNumber (#PCDATA | xlink:group)* >

<!ELEMENT xlink:group (xlink:document*)>
<!ATTLIST xlink:group
   xmlns:xlink CDATA   #FIXED  "http://www.w3.org/XML/XLink/0.9"
   steps		CDATA			"2" 
>

<!ELEMENT xlink:document (#PCDATA) >
   <!ATTLIST xlink:document
   xmlns:xlink CDATA   #FIXED  "http://www.w3.org/XML/XLink/0.9"
   href		CDATA			#REQUIRED 
>

<!-- Altnames are other names besides the title by which the
	dataset may be identified.
	ADC = Astronomy Data Center (NASA/GSFC)
	CDS = Centre de Donnees astrophysique de Strasbourg
-->
<!ELEMENT altname (#PCDATA) >
   <!ATTLIST altname
   type     (CDS|ADC|brief|common|other)  #REQUIRED 
>

<!-- reference refers to the source of the data.  That source may
     be a book, a chapter in a book, an article in a journal, or some
     other source. But reference may refer to some other important
     source of information about the dataset.  This may be deprecated
     because of the related below. 
-->
<!ELEMENT references (reference*) >
   <!ATTLIST references type (related|source) "source" >
<!ELEMENT reference (title?,author+,et_al?,
		(holding|journal|book|inBook|privateCom|other|url|ftp|telnet))> 

<!ELEMENT author (((prefix?, firstName?, initial*, middleName*,
	lastName, suffix?, institution?) | institution+), 
	address?, email?, phone?, url?) > 
<!ELEMENT prefix (#PCDATA) >
<!ELEMENT firstName (#PCDATA) >
<!ELEMENT initial (#PCDATA) >
<!ELEMENT middleName (#PCDATA) >
<!ELEMENT lastName (#PCDATA) >
<!ELEMENT suffix (#PCDATA) >
<!ELEMENT institution (#PCDATA) >
<!ELEMENT email (#PCDATA) >
	<!ATTLIST email 
	%locator.att;
	%simple-link-semantics.att; 
	%remote-resource-semantics.att; 
>
<!ELEMENT phone (#PCDATA) >

<!ELEMENT et_al EMPTY >
   <!-- altname gives the ADC ID, the CDS ID, the brief title, and
	other names for this dataset.  Acronyms should go in as a brief
	title -->

<!ELEMENT url (#PCDATA) >
   <!ATTLIST url 
   %locator.att; 	
   xlink:type   (simple|extended|locator|arc)  #FIXED  "simple"
   %remote-resource-semantics.att;
   %local-resource-semantics.att;
   %simple-link-semantics.att; >
<!ELEMENT telnet (#PCDATA) >
   <!ATTLIST telnet 
   %locator.att; 	
   xlink:type   (simple|extended|locator|arc)  #FIXED  "simple"
   %remote-resource-semantics.att;
   %local-resource-semantics.att;
   %simple-link-semantics.att; 
>
<!ELEMENT ftp (#PCDATA) >
   <!ATTLIST ftp 
    %locator.att; 	
    xlink:type   (simple|extended|locator|arc)  #FIXED  "simple"
    %remote-resource-semantics.att;
    %local-resource-semantics.att;
    %simple-link-semantics.att; 
>
<!ELEMENT holding (#PCDATA | url)* >
   <!ATTLIST holding
	role (superceded|supercedes|related|similar) #REQUIRED 
>


    <!-- journal/name is the title of the journal. journal/title
	is the title of the article within the journal -->
<!ELEMENT journal (name, volume?, pageno?, date, bibcode?) >
   <!ATTLIST journal 
	status (inPress|submitted|inPreparation) #IMPLIED 
>
<!ELEMENT name (#PCDATA | footnote)* >
<!ELEMENT volume (#PCDATA) >
<!ELEMENT pageno (#PCDATA) >
<!ELEMENT date (year, month?, day?) >
<!ELEMENT year (#PCDATA) >
<!ELEMENT month (#PCDATA) >
<!ELEMENT day (#PCDATA) >
<!ELEMENT bibcode (#PCDATA | url)* >
<!ELEMENT book (series?, volume?, publisher, city, date, bibcode?) >
   <!ATTLIST book 
	status (inPress|submitted) #IMPLIED 
>
<!ELEMENT series (#PCDATA) >
<!ELEMENT publisher (#PCDATA) >
<!ELEMENT city (#PCDATA) >

	<!-- inBook/name is the title of the book. inBook/title
	is the title of the article or chapter within the journal -->
<!ELEMENT inBook ( name, series?, volume?, editor*, 
	publisher, city?, pageno?, date, bibcode?) >
   <!ATTLIST inBook 
	status (inPress|submitted) #IMPLIED 
>
<!ELEMENT editor (prefix?, firstName?, initial*, lastName,
	suffix?, institution?) >
<!ELEMENT privateCom (#PCDATA | date)* >
<!ELEMENT other (name, series?, volume?,
	editor*, publisher?, city?, pageno?, date, bibcode?, url? ) >
   <!ATTLIST other 
	type    CDATA  		#IMPLIED 
>
<!ELEMENT footnote (#PCDATA | author | para)* >
   <!ATTLIST footnote
	type (nomenclature)  #IMPLIED
	xml:space (default | preserve)   "default" 
	footnoteId    ID     #IMPLIED 
	footnoteIdRef   IDREF     #IMPLIED 
>

   <!-- keywords is an xlink:group that several keyword.
	list gives the parentListURL gives the URL for the
	list of all keywords from which the keywords were chosen.
	Since there are several parentLists there can be more than
	one set of keywords.  That is, keywords groups together those
	keyword* that are from the same parentList.
   -->
<!ELEMENT keywords (keyword*) >
   <!ATTLIST keywords 
	xmlns:xlink	CDATA	#FIXED "http://www.w3.org/XML/XLink/0.9"
	xlink:type 	(group)  #FIXED "group"
	parentListURL   CDATA     #IMPLIED 
	xlink:steps  	CDATA  		"2" 
>

   <!-- Each keyword is a link to a document that links to other
        datasets that use the same keyword. Since it is inside of an
        xlink:group it is an xlink:document.
    -->
<!ELEMENT keyword (#PCDATA) >
   <!ATTLIST keyword
   xmlns:xlink     CDATA       #FIXED  "http://www.w3.org/XML/XLink/0.9"
   xlink:type 	(document)  #FIXED "document"
   xlink:href	CDATA	    #REQUIRED 
>

   <!-- 
	DESCRIPTION is information helpful in selection decisions for  
	this particular dataset.  It can contain an ABSTRACT
	which is generally the abstract of the article if the tables originate
	from a journal article.  It also can contain DETAILS which has  more
	specific information useful to anyone making use of the data.
    -->
<!ELEMENT descriptions (description | abstract | details)+ >
	<!ATTLIST descriptions 
	xml:lang        NMTOKEN		"en" 
>

<!ELEMENT description  (#PCDATA|heading|para)* >
<!ELEMENT heading (#PCDATA) >

    <!-- para is a paragraph and this may have all sorts
	 of  tagged information. To preserve spacing as typed
	 use the attribute xml:spacing="preserve". 
     -->
<!ELEMENT para (#PCDATA | address | institution | observatory | telescope
		| instrument | equinox | epoch |  reference 
		| database | fileName | hardware | software 
		| project | url | footnote)* >
	<!ATTLIST para 
	xml:space (default|preserve)   "default" 
>
<!ELEMENT address (#PCDATA | street | postOfficeBox | postcode
	| city| state | country )* > 
<!ELEMENT street (#PCDATA) >
<!ELEMENT postOfficeBox (#PCDATA) >
<!ELEMENT postcode (#PCDATA) >
<!ELEMENT state (#PCDATA) >
<!ELEMENT country (#PCDATA) >
<!ELEMENT equinox (#PCDATA) >
<!ELEMENT epoch (#PCDATA) >
<!ELEMENT observatory (#PCDATA | url)* >
	<!ATTLIST observatory
	base		(ground|air|space)	"ground" 
>
<!ELEMENT telescope (#PCDATA | url)* >
<!ELEMENT project (#PCDATA | url)* >
<!ELEMENT instrument (#PCDATA | url)* >
<!ELEMENT database (#PCDATA | url)* >
<!ELEMENT fileName (#PCDATA | url)* >
<!ELEMENT hardware (#PCDATA | url)* >
<!ELEMENT software (#PCDATA | url)* >
<!ELEMENT abstract (para*) >
<!ELEMENT details  ((heading | para)*, astroObjects?) >
   <!-- astroObjects provides for a list of astronomical objects that
	the tables deal with.  This is optional and is probably only useful
	if the number of astroObjects is small.  
    -->
<!ELEMENT astroObjects (astroObject+) >
<!ELEMENT astroObject  (name*, position) >
	<!ATTLIST astroObject
	footnoteIdRef		IDREF		#IMPLIED 
>
<!ELEMENT position (coordinates?, (ra | gl | sgl | lon )?, 
			(dec?  | gb | sgb | lat )? ) >
	<!ATTLIST position
	footnoteIdRef		IDREF		#IMPLIED 
>
<!ELEMENT ra (#PCDATA) >
<!ELEMENT gl (#PCDATA) >
<!ELEMENT sgl (#PCDATA) >
<!ELEMENT lon (#PCDATA) >
<!ELEMENT dec (#PCDATA) >
<!ELEMENT gb (#PCDATA) >
<!ELEMENT sgb (#PCDATA) >
<!ELEMENT lat (#PCDATA) >
<!ELEMENT tables ((structure|array|fitsFile)+) >
<!ELEMENT images ((structure|array|fitsFile)+) >
<!ELEMENT spectra ((structure|array|fitsFile)+) >
					
   <!-- XDF  has the information for tables.  -->

<!--  XDF_ADC.dtd - eXtensible Data Format - version 0.1.3
	Date: Feb 24, 2000
	XML lanaguage Document Type Definition (DTD).

	This is the version just for the ADC.  It adds some more 
	contents to the field elements that are used in that archive.
	An XDF document contains arrays and data structures.  It  is
	designed to be both an interchange format for scientific data 
	and to be of archival quality.
	Multidimensional tables and scalar or vector fields are represented
	in a consistent way and become thoroughly self describing.
        Axial information is well described so that the space in which 
	each part of the data structure resides is fully described.  
	This means that XDF provides a consistent way to hold spectra 
	with their wavelength scales, images with coordinate axes, 
	vector fields with component directions, data cubes in complicated 
	spaces, tables with column headers, and series of tables
	with each table having a unique name. 

-->
<!ENTITY nbsp   "&#160;" ><!--=no break (required) space-->
<!--
<!ELEMENT XDF ((parameter | array | samples | structure)+)>
<!ATTLIST XDF
	name        CDATA       #IMPLIED
	description CDATA       #IMPLIED
>
-->
<!--    One might wish to set some simple parameters
	before or within the data structures.
	These parameters, if outside of a structure,
	refer globally to all structures following, unless overridden
	by the same named parameter or array within the structure or by
	a later occurrence outside of any structure.  
-->
<!ELEMENT parameter (value | values)>
<!ATTLIST parameter
	name        CDATA   #IMPLIED
	description CDATA   #IMPLIED
	units       NMTOKEN #REQUIRED
>
<!--    The units should be written out without abbreviations to
	avoid ambiguity, unless SI units are used.  When non SI are
	used, the singular form should be chosen.  units="unitless" means
	unitless, units="" means undefined or unknown. Units are multiplied
	together with a '.' , divided with a '/', and raised to a power
        needs no symbol.  Units can begin with a constant multiplier in
	fixed format or in E (exponential) format. 
	Example, 1E8.km3.g/s means 1x10^8 cubic kilometers grams per second. 
	-->
<!--    For the 'value' of the parameter, the attribute special is used
	to set the data to infinity, negative infinity, noData.  
        The noData implies that the value is unknown. 
	When special is used the value element should be empty.
	The inequality is used to indicate that the parameter is not
	necessarily equal to the value, but is limited in some way by 
	this one value is being set.  The datatype of the value is the
	the same as the datatype of the parameter, therefore, when an
	inequality is used with datatype integer the parameter is set to
	all integers satisfying the constraint.
	Note that if datatype is not integer and an inequality is set,
	then the possible values of the parameter are infinite. 
	A new value for a parameter overrides the previous one
	as per the rules above, but when inequality2 attribute is 
	used, and it is not inconsistent with the previous inequality,
	then both inequalities hold.  This is how a parameter can be
	constrained to a finite range.
-->
<!ELEMENT value (#PCDATA)>
<!ATTLIST value
	special (infinite | infiniteNegative | noData) #IMPLIED
	datatype (integer | float | exponential | string) #IMPLIED
	inequality (lessThan | lessThanOrEqual | greaterThan | greaterThanOrEqual) #IMPLIED
	inequality2 (lessThan | lessThanOrEqual | greaterThan | greaterThanOrEqual) #IMPLIED
>
<!--
	To associate a list of values to a parameter use element values.  
	One can fill it with a delimited set of values, or a call to 
	a web site to fill it in, or use a script such as ECMAscript.
	The escape character allows one to use the delimiter in the
	data string.  To use the escape character type it twice.
-->
<!ELEMENT values (#PCDATA | value | script | component | field | group)*>
<!ATTLIST values
	name               CDATA                                   #IMPLIED
	size               NMTOKEN                                 #REQUIRED
	delimiter          CDATA                                   " "
	escape             CDATA                                   "\"
	start              NMTOKEN                                 "1"
	step               NMTOKEN                                 "1"
	datatype          (integer | fixed | exponential | string) #IMPLIED
	functionHref      CDATA                                    #IMPLIED
	fieldIDRef     IDREF                                    #IMPLIED
	infiniteValue     NMTOKEN                                  #IMPLIED
	infiniteNegativeValue NMTOKEN                              #IMPLIED
	noDataValue       NMTOKEN                                  #IMPLIED
>
<!ELEMENT script (#PCDATA)>
<!ATTLIST script
	type (ECMA | Java | Perl) "ECMA"
>
<!--  There are several ways to fill the values array:
	1) delimited values
		<values size="3">1.3 2.3 3.7</values>
		<values size="3">M31 NGC1316 Milky&nbsp;Way</values>

         2) A function like response from a URL
		<values size="601" functionHref="http://adc.gsfc.nasa.gov/cgi-bin/java/ArrayFill.pl?start=0&end=1200&step=2" />
	The client would need to have the function ArrayFill. 

	 3) Use built-in facilities
		<values size="601" start="0" step="2" />

         4) Use a programming script:
     <values size="601"><script type="ECMA">
     		for (i=0;i<=1200;i+=2)
     		{document.write(i + " ");}</script></values>
	-->
<!-- 	An array is a set of mixed native datatype data (strings
	and numbers) that are to be read into a variable.  The 
	variable can have any number of dimensions.  The array is therefore
	rectilinear (although other possibilities may someday be
	introduced).  Array carries information about each of these dimensions.  -->
<!ELEMENT array (parameter*, axis+, read, (mtable | data), notes?)>
<!ATTLIST array
	name        CDATA                           #IMPLIED
	description CDATA                           #IMPLIED
	units       NMTOKEN                         #IMPLIED
	tableNumber   NMTOKEN                       #IMPLIED
>
<!-- Each dimension of an N-dimensional structure is introduced by
	a axis element.  

   Example,
   <axis name="vector components"  >
      <values size="3">
        <component>x</component><component>y</component><component>z</component>
      </values>
   </axis>
   <axis name="x" units="cm">
        <values size="6">0 1 2 3 4 5</values>
   </axis>
   <axis name="y" units="cm" >
         <values size="4">60 62 64 68</values>
   </axis>
   <axis name="z" units="m" >
	<values size="7">0 1 2 3 4 5 6</values>
   </axis>

	This describes a cartesian vector field in a 3-d space of 6cm by
	8cm by 7 m.  The data is read in with the most nested data first,
	ie the z-data contained in the x component of the x=0,y=60 slice.
	-->
<!-- axis/values is a list of numbers or strings (space delimited with
	quotes where necessary) that describes one dimension of the array,
	as in, the wavelength scale of a spectrum, or distance along
	the width of an image.	The number of elements should match the
	size attribute. In curvilinear coordinates the axis merely describe
	the positions of the edges of the region bound by the array.  A
	more full description of the space coordinates can be done with
	a field/@type="spatial" map.  The units attribute refers to 
	the units of the
	axis/values not to the array.  A function could be use to fill
	in the values without having to actually contain the values in
	the document.  -->
<!ELEMENT axis (values*)>
<!ATTLIST axis
	name        CDATA   #IMPLIED
	description CDATA   #IMPLIED
	axisID      ID      #IMPLIED
	axisIDRef   IDREF   #IMPLIED
	units       NMTOKEN #IMPLIED
>
<!-- A vector field is represented by a series of arrays and
	is described by component elements.  This could be "x-hat",
	"y-hat", and "z-hat". When the direction is along one of the
	axes an axisIDRef can point to that axis.
	Component can also be used to represent complex number with the 
	attribute imaginary set to "yes" in the imaginary component 
-->
<!ELEMENT component (#PCDATA)>
<!ATTLIST component
	imaginary    (yes | no) #IMPLIED
	description   CDATA     #IMPLIED
	axisIDRef     IDREF     #IMPLIED
>
<!-- a table or a set of tables can be formatted in XDF. In the same
	way that axis describes the value for each column in an image,  field
	elements are used to describe each column in the table.  Normally,
	a set of tables would have a field for each table.
	
      	<axis name="Galaxy Name" >
	   <values size="3">M31 M33 Milky&nbsp;Way </values>       
       </axis>
       <axis name="properties of Galaxies" >
	   <values size="2" name="position">
	      	<field units='sexigesimal'><name>right
ascension</name></field>
	      	<field units="sexigesimal"><name>declination</name></field>
            </values>
	    <values size="2"
	      <field units="mag"><name>B-band Flux</name>
	      </field>
	      <field units="mag"><name>V-band Flux</name>
              </field>
            </values>
      	</axis>

	Another use for field is to hold several images with 
	different datatypes, ie:
    	<axis name="Full Image Data Set" >
	  <values>
	    <field units="Jansky" fieldID="rawData">
		<name>raw data</name>
            </field>
	    <field units="unitless">
		<name>sensitivity</name>
		<relation fieldIDRef="rawData" role="sensitivity" />
            </field>
	    <field units="Jansky" fieldID="reducedData>
		<name>reduced data</name></field>
	    <field units="milliJansky">
		<name>errors</name>
		<relation fieldIDRef="reducedData" role="errors"/>
	   </field>
	  </values>
	</axis>
	<axis name="Vertical Axis" >
		<values size="512"/>
	</axis>
	<axis name="Horizontal Axis" >
		<values size="512"/>
	</axis>	
-->
<!-- field usually describes the columns of a table, or it
	can be used simply as a name for an individual table in a
	set of tables. A special type of field is type="spatial"
       which is useful for coordinate transformation maps when
       one needs to transform from i,j,... in the data space to 
      some chosen coordinate space. Generally, this requires one
      map for each coordinate and each map is of the same size as 
      the initial data (a function can be used to extend the data to
      include this information.) -->
<!ELEMENT field (name,notes?,footnote*,relation?,
			min?,max?,coordinates?)>
<!ATTLIST field
	type                   (spatial)  #IMPLIED
	description            CDATA      #IMPLIED
	units                  CDATA      #IMPLIED
	infiniteValue          NMTOKEN    #IMPLIED
	infiniteNegativeValue  NMTOKEN    #IMPLIED
	noDataValue            NMTOKEN    #IMPLIED
	class  	NMTOKENS		  #IMPLIED
	type       (observed|derived|cited)  #IMPLIED 
	fieldID             ID            #IMPLIED
	fieldIDReF       IDREF            #IMPLIED
	footnoteIdRef    IDREF            #IMPLIED
>
	<!-- For class attribute chose multiple words from this list
		(abundance|brightness|class|color|density|diameter|energyDensity|
		equivalentWidth|error|frequency|gamma-ray|infrared|latitude|longitude|
		luminosity|millimeter|morphologicalType|multiplicity|name|note|number|
		opacity|optical|parallax|polarization|position|properMotion|quality|
		radialVelocity|radio|radius|separation|spectralIndex|spectralType|
		temperature|time|ultraviolet|units|velocity|x-ray)		
-->
<!ELEMENT min  (#PCDATA)>
<!ATTLIST min
	type      (actual|legal) "legal"
	inclusive (yes|no) "yes"
>
<!ELEMENT max  (#PCDATA)>
<!ATTLIST max
	type      (actual|legal) "legal"
	inclusive (yes|no) "yes"
>
<!ELEMENT coordinates EMPTY >
	<!ATTLIST coordinates
	system (ecliptic|FK4|FK5|galactic|supergalactic|ICRS) #IMPLIED 
	equinox  NMTOKEN     #IMPLIED 
	epoch    NMTOKEN     #IMPLIED 
>

<!-- 	Relationships between properties can be expressed with the relation
	element, a child of field.  Measurements and their errors
	could linked in this way. -->
<!ELEMENT relation EMPTY >
<!ATTLIST relation
	fieldIDRef    IDREF     #REQUIRED 
	role    (errors | sensitivity | weights | references | noteMarks)
				   #REQUIRED
>
<!ELEMENT group ((group | values)+)>
<!ATTLIST group
	name     CDATA      #IMPLIED
>
<!--    The element type group can be used to group together field+ 
	and gives a common name to the set.  
	For instance, longitude and latitude may be grouped
	together with name="position".	Measurements and their errors
	could also be grouped together in a natural way. -->
<!ELEMENT notes ((index|noteMark), note)+>
<!ELEMENT index (#PCDATA | index)*>
<!ELEMENT note (#PCDATA) >
<!ELEMENT noteMark (#PCDATA) >
<!--  Each array can contain notes to individual elements within
the array. 
The index is a nested in the same way that axis is nested:
<notes>
       <index>4<index>3<index>2</index></index></index>
       <value>A higher resolution image exists for this element</value>
       <index>6<index>2<index>1</index></index></index>
       <value>No data because of a cosmic ray hit</value>
</notes> -->
<!--    read elements are instructions for reading in the data, 
	they reference to the axis elements and show the order 
	for filling up the n-dimensional variables by their nesting.  
	The format information and the data appear inside the most 
	nested read element.
-->
<!ELEMENT read (read | (recordFormat | binaryFormat | delimiter))>
<!ATTLIST read
	axisIDRef IDREF #REQUIRED
>
<!ELEMENT mtable (mtr+)>
<!ELEMENT mtr ((mtr | mtd)+)>
<!ELEMENT mtd (#PCDATA)>
<!-- recordFormat will have a series of text or binary format elements
one for each element until the end of a record (at the terminator).
Or, if there are no terminators, the entire set of formats are 
repeated until the end of the data. Not to be confused with using a
repeat element to repeat a particular format specifier a certain number
of times before moving on to the next specifier -->
<!ELEMENT recordFormat ((text | repeat | skipChar)+)>
<!ATTLIST recordFormat
	encoding        (UTF-8 | UTF-16)          "UTF-8"
	terminator (newLine | carriageReturn) "newLine"
	formatID      ID 			      #IMPLIED
	formatIDREF   IDREF 			      #IMPLIED
>
<!ELEMENT repeat ((text | skipChar | binary)+)>
<!ATTLIST repeat
	count NMTOKEN #REQUIRED
>
<!ELEMENT skipChar EMPTY>
<!ATTLIST skipChar
	count NMTOKEN    "1"
>
<!ELEMENT text EMPTY>
<!ATTLIST text
	type (fixed | exponent | integer | string) #REQUIRED
	flags (leftJustify | prefixPlusSign | octal | hexadecimal | zeroPad) #IMPLIED
	width     NMTOKEN #REQUIRED
	precision NMTOKEN #IMPLIED
>
<!ELEMENT binaryFormat ((binary | repeat)*)>
<!ATTLIST binaryFormat
	endian        (BigEndian|LittleEndian)          "BigEndian"
	encoding      (uuencoded|base64)                 #IMPLIED
	terminator (newLine | carriageReturn) "newLine"
	delimeter CDATA #IMPLIED
	formatID      ID 			      #IMPLIED
	formatIDREF   IDREF 			      #IMPLIED
>
<!ELEMENT binary EMPTY>
<!ATTLIST binary
	type (boolean | string | integer | float) #REQUIRED
	signed (yes | no) "yes"
	bits (1 | 2 | 4 | 8 | 16 | 32 | 64 | 80 | 128) #REQUIRED
>
<!ELEMENT delimiter EMPTY>
<!ATTLIST delimiter
	string       CDATA    " "
	repeatable (yes | no) "yes"
>
<!-- The Data element is a very general container for data.
	It could be marked up as rows and cells with mtr and mtd
	(MathML) or it can be fixed format or delimited.  If there are
	no elements within it, it can begin with a &lt;&lt;![CDATA[ and
	end with ]]>.  However, a data element may contain data elements
	within it.  For instance, an animation would be a set of frames
	and it may be convenient to bracket each frame with a data tag.
	These data tags are not needed to build the structure because the
	structure is prescribed by the axis element.  Nevertheless,
	an application can use the nested data tags to indicate exactly
	where a problem lies in the data and aid in editing.  Also, the application 
	can use parts of the structure as soon as it hits some close
	data tags.  The parser can pass the images to the display applet
	rather than waiting for the entire data set to arrive.	Of course,
	external entities can be used, so that the data
	may resides in one or several separate physical files. -->
<!ELEMENT data (#PCDATA | data)*>
<!ATTLIST data
	href                  ENTITY              #IMPLIED
	xml:space           (default | preserve) "preserve"
	infiniteValue         NMTOKEN             #IMPLIED
	infiniteNegativeValue NMTOKEN             #IMPLIED
	noDataValue           NMTOKEN             #IMPLIED
	checksum              NMTOKEN             #IMPLIED
	compression (zip | gzip | XMILL | compress) #IMPLIED
>
<!ELEMENT samples (index, value)*>
<!ATTLIST samples
	name                  CDATA               #IMPLIED
	description           CDATA               #IMPLIED
	units                 NMTOKEN             #IMPLIED
>
<!--  Each structure can contain samples to individual elements. 
<samples name="X Observations" description="A few targeted observations"
      units="W/s/cm2/Hz/sterad">
      <index>4<index>3<index>2</index></index></index>
      <value>23.54</value>
      <index>6<index>2<index>1</index></index></index>
      <value>18.54</value>
      <index>6<index>2<index>1</index></index></index>
      <value>23.34</value>
      <index>6<index>2<index>1</index></index></index>
      <value>11.14</value>
</samples> -->
<!-- A structure holds one or more arrays.  This is usually
	the main element of the document. -->
<!ELEMENT structure ((array | samples | parameter)+)>
<!ATTLIST structure
	name          CDATA   #IMPLIED
	description   CDATA   #IMPLIED
	units         NMTOKEN #IMPLIED
>
<!-- End of XDF.dtd -->

<!ELEMENT fitsFile  (name,description) >
	<!ATTLIST fitsFile 
	type	CDATA   #IMPLIED
	size	CDATA	#IMPLIED
	xlink:type   (simple|extended|locator|arc)  #FIXED  "simple"
	%locator.att; 	
	%remote-resource-semantics.att;
     	%local-resource-semantics.att;
     	%simple-link-semantics.att; >

<!ELEMENT textFile (name,description,(postscript|PDF)*) >
	<!ATTLIST textFile 
	size	CDATA	#IMPLIED
	xlink:type   (simple|extended|locator|arc)  #FIXED  "simple"
	%locator.att; 	
	%remote-resource-semantics.att;
     	%local-resource-semantics.att;
     	%simple-link-semantics.att; 
>

<!ELEMENT postscript (#PCDATA) >
<!-- <!ATTLIST postscript 
	show  NOTATION #FIXED "ps">
	<postscript show="ps">gsave 112 75 moveto 112 300 lineto 
	showpage grestore ... </postscript> 
-->

<!ELEMENT PDF (#PCDATA) >
<!--<!ATTLIST PDF 
	show  NOTATION #FIXED "pdf">
-->
<!ELEMENT footnotes (footnote+) >


  <!-- history contains information on who wrote the document, when, and
	who helped.  It also contains an identifier which gives the
	URL for the original version of this document -->
<!ELEMENT history (ingest?, revisions?) >
<!ELEMENT ingest (creator+,date,acknowledgement?,para*) >
<!ELEMENT creator (prefix?, firstName?, initial*, 
		middleName?, (lastName|software|staff), suffix?, institution?) >
<!ELEMENT staff EMPTY >
<!ELEMENT acknowledgement (#PCDATA) >
  <!-- REVISIONS are intended to take the place of .history files -->
<!ELEMENT revisions (revision+) >
<!ELEMENT revision (creator+,date,para+) >
<!ELEMENT identifier (#PCDATA) >