XDELTA DTD

See: http://www.bath.ac.uk/~ccslrd/delta/xdelta.dtd

<!-- 
      ====================================================================
                                 XDELTA
      ====================================================================
      
      This is the first public draft DTD for the XDELTA format. XDELTA
      is an XML format which is derived from the DELTA format for describing
      taxonomic data. 
      
      More information about DELTA can be found at:
      

      http://biodiversity.uno.edu/delta/
      

      More information about XDELTA can be found at:
      

      http://www.bath.ac.uk/~ccslrd/delta/index.html


      The latest version of this DTD can be found at:
      

      http://www.bath.ac.uk/~ccslrd/delta/xdelta.dtd
      

      This DTD should be considered to be a work-in-progress and is thus
      liable to change. It is also not a new standard for storing taxonomic 
      data, but an example of what such format such a standard may take.
      
      It is expected that further work will be carried out on this DTD after
      public comment and review. 
      
      You can contact the author at: 
      
      ldodds@ingenta.com
      


      Revision History:
      
      Date        Author         Change Notes
      ====================================================================
      21/10/1999  leigh          Produce first public draft, with comments.
      
      
      ====================================================================
-->


<!-- =====================  Entity declarations   ====================== -->

<!-- Pseudo character values as defined in DELTA. -->
<!ENTITY % variable   "V">
<!ENTITY % unknown    "U">
<!ENTITY % notapplicable "-">


<!-- ================ Element and Attribute declarations   ============= -->

<!-- A comment is basically plain text. In DELTA a comment signifies more than
     just a textual note - it can contain the authority, additional text for
     natural language conversions, character notes, etc. Some attempt has been
     made to separate this out in this initial draft 

     A comment can contain additional embedded comments.
-->
<!ELEMENT comment     (#PCDATA | comment)*>

<!-- An image. An image can have associated text (e.g. a title). An image can
     be numbered (to allow cross-referencing between images within a document.
     Image numbers should be unique within a document.
     
     An image must be provided with a location (href). For location applications 
     this href attribute will likely be a file system reference. However to allow 
     for internet based resolution the location may be a URL (or potentially a URN).   
     
     The mime type of the image must also be provided in the mime attribute. This 
     allows applications to determine the image type without having to download 
     or otherwise process the image. e.g. image/gif. An application can therefore 
     avoid downloading/processing any image type that it cannot handle.
     
     e.g. image href="http://www.bath.ac.uk/~ccslrd/lepidoptera.gif" type="image/gif"

     The height and width of an image can also be supplied if this information is 
     available to the author.

     TODO - is requiring the mime type excessive? its certaintly useful, and could
     save bandwidth should an application not be able to display the image. Less of
     an issue for purely local usage.

     TODO - should image elements allow for specifying regions within an image. So 
     that, for example, only a part of an image is displayed? Or can this be handled 
     by image references? Perhaps we need an show attribute - indicating to the 
     application whether an image should be displayed (by default) or not?
     
-->     
<!ELEMENT image (#PCDATA)*>
<!ATTLIST image num  CDATA #IMPLIED
                href CDATA #REQUIRED
                mime CDATA #REQUIRED
                h    CDATA #IMPLIED
                w    CDATA #IMPLIED>

<!-- This is a reference to a previously defined image in an XDELTA document. It allows
     the author to avoid replicating information which is already available. Referencing 
     is achieved through the num attribute which should correspond to the num attribute
     of an existing image in the document.

     TODO - referencing (rectangular) regions within an image, to allow image-map/hotspot 
     style handling of image data. Requires x1,y1,x2,y2 attributes. The DELTA format 
     uses 'image-units' to achieve this. XDELTA should use pixel co-ordinates, as this 
     seems a more standardised approach (cf : HTML image maps).
     
-->
<!ELEMENT image-ref  EMPTY>
<!ATTLIST image-ref  num   CDATA #REQUIRED>


<!-- A value for a character. DELTA allows character values to be expressed in several
     forms, depending on the type of character.
     
     e.g. real             e.g. 2.5 
          integer          e.g. 10
          range            e.g. 1-2    (between x and y)
          bounded range    e.g. (1-)4-5 or 4-5(-6) or (1-)4-5(-6)
          alternates       e.g. 3/4    (x or y)
          combinations     e.g. 6&7    (x and y)
     
     Composite Values can be quite complex. e.g. 1/2/3/5&6 (a or b or c or (d & e)).
     
     XDELTA allows this same level of expressiveness, but in an attempt to limit 
     the number of elements required (to express the range, and logical operators required), 
     only a single element defines these types of value. 
     
     The following demonstrates the examples above.
     
     e.g. real          <value>2.5</value>
          integer       <value>10</value>    
          
          The difference between real/integer is defined already for numeric characters.
          
          range         <value start="1" end="2" /> or
                        <value start="1" end="3">2</value>  
               
     The second case defines 1-2-3 from DELTA, which only allows three values in a range,
     the interpretation as to which value is the median/mode is obvious in the second case,
     i.e. 2. Following the DELTA example, the media/mode is 1 in the first. In the 
     general case, a two value range should be expressed by the start/end attributes, and 
     a three value range using the start/end and content of the element.
          
          bounded range <value lower="1" start="4" end="5" />  or
                        <value start="4" end="5" upper="6" />  or
                        <value lower="1" start="4" end="5" upper="6" />
          
          alternates    <value>1</value><value>2</value>
          
     Elements containing value children should allow multiple values to allow for this.
          
          combinations  <value><value>6</value><value>7</value></value>
          
     A value can contain other values.
          
     In usage then value elements which are siblings are assumed to define alternates 
     (logical OR); value elements which are children of another value are assumed to 
     be a combination (logical AND).

     This setup still allows complex character values to be expressed.
     
          <value>1</value>
          <value>2</value>
          <value>3</value>
          <value>
            <value>5</value>
            <value>6</value>
          </value>
          
      defines 1/2/3/5&6.
          
      NOTE: I'd like feedback on this part of the modelling particularly. I've attempted to 
      balance the requirement that XDELTA should have the same expressiveness as DELTA 
      against the need to avoid having multiple different elements for each different type 
      of value (e.g. <bounded-range>, <range>, <combination>, <alternate>, or other 
      complex model). The latter may make processing slightly easier, but makes mark-up 
      of information by hand more difficult (additional tags to remember).

      It would have been simple to model the value element as simply #PCDATA and allow the DELTA 
      values to be copied directly into it: e.g. <value>(1-)4-5</value> but while this is very 
      easy to mark-up, it involves additional application processing to parse out the 
      meaning of the content - this seems against the spirit of producing an XML syntax: all 
      data should be present in mark-up of some form.

      A value can also contain (multiple) comments.
-->     
<!ELEMENT value      (#PCDATA | value | comment)*>
<!ATTLIST value      lower    CDATA    #IMPLIED
                     start    CDATA    #IMPLIED                     
                     end      CDATA    #IMPLIED
                     upper    CDATA    #IMPLIED>

<!-- Notes associated with a character. Allows embedded comments -->
<!ELEMENT notes (#PCDATA | comment)*>

<!-- A numeric character. The type of number must be specified - either real or integer.
     Can have optional units specified.
-->
<!ELEMENT num   EMPTY>
<!ATTLIST num  type  (real|integer) #REQUIRED
               units CDATA    #IMPLIED>


<!-- A text character. Can contain only plain text, no comments. 

     TODO: should we allow comments?
-->
<!ELEMENT txt  (#PCDATA)>


<!-- A state. Part of a multistate character. A state must have an associated number which 
     uniquely identifies it within its character.
     
     A state can contain plain text, comments, images and image references. There are 
     no restrictions on this. 
     
     NOTE : this content model seems quite loose (it can contain an unlimited about of 
     images, comments, text, etc.). This is caused by a restriction in XML which requires 
     the content model of (x | y | z)* if x is #PCDATA. There are workarounds for this 
     involving adding additional 'wrapping' elements. This would add another element 
     type to the DTD however. This may not be a problem as large amounts of descriptive text 
     *may* be useful.
-->
<!ELEMENT state (#PCDATA | comment | image | image-ref)*>
<!ATTLIST state number  CDATA #REQUIRED>

<!-- A multistate character. Ordered and unordered states can be identified by the 
     type attribute. If not specified then the default is unordered as in DELTA.
     
     A multistate character must contain at least one state.

     DELTA has the concept of 'implied' characters which allows certain attributes or states
     to be omitted from items. The omitted attributes or values are assigned default values.
     The DELTA standard states that only multistate characters can be implied. Modelling
     this in XDELTA gives us two optional attributes which can be added to multistate
     characters - the first 'implied' specifies the value that a character is assigned if
     it is missing from an item description. The second 'default' specifies the value that
     a character should take if the character is present but not assigned any value.

     While it cannot be enforced by the DTD it should be an error for the 'default' attribute
     to be specified without the 'implied' attribute, the simplest course of action
     should be to just warn the user and ignore the attribute.
-->
<!ELEMENT multi   (state+)>
<!ATTLIST multi   type  (ordered|unordered)  "unordered"
                  implied       CDATA        #IMPLIED
                  default       CDATA        #IMPLIED>

<!-- For dependent characters. Dependencies can only be expressed between
    multistate characters in DELTA. Rather than list dependencies within
    individual characters, we list the *dependents* within a controlling
    character. This means all data is kept in one place, akin to the
    DEPENDENT CHARACTERS directive. Otherwise state dependencies would 
    be duplicated throughout the document. 
    
    A dependency-list can contain multiple values and or dependents.
    Value children represent alternates (see definition of
    value element above).
    
-->
<!ELEMENT dependency-list  (value, dependent)*>
<!-- the dependent character, identified by the character attribute -->
<!ELEMENT dependent  EMPTY>
<!ATTLIST dependent  character   CDATA #REQUIRED>

<!-- A DELTA character. A character must be uniquely numbered within a document.

     A character must have a description, and can contain an optional comment, 
     and/or image and/or additional notes. A character must contain a multi(state) 
     num(eric) or txt element. A character may also contain a dependency list which
     describes the other characters which are controlled by this character.

     
     TODO : should a character allow multiple dependency lists? e.g. state 
     values 1-2 may invalidate characters x-y, state values 3-4 may invalidate 
     characters m-n, etc. Its not clear from DELTA whether this is/should be 
     permitted. Logically I'd assume so, but leave only a single list at present.
     
-->
<!ELEMENT character  (description, comment?, image?, (multi|num|txt), notes?, dependency-list?)>
<!ATTLIST character  number   CDATA #REQUIRED>

<!-- A character group allows the grouping of related characters together. DELTA does 
     not enforce the grouping of characters, and neither does XDELTA. However the 
     CHARACTER HEADINGS directive seems to assume that related characters will be 
     grouped together within a DELTA file (as it only specifies the first character 
     that falls under each heading). XDELTA therefore allows characters to be grouped 
     in this way.
     
     A group can have an optional title
-->        
<!ELEMENT char-group (character)*>
<!ATTLIST char-group title    CDATA #IMPLIED>

<!-- A list of characters. A character-list can contain zero or more characters and/or 
     character-groups (char-group).
-->
<!ELEMENT character-list (character | char-group)*>


<!-- A DELTA attribute. An attribute refers to a given character (as defined by its
     attribute. An attribute may contain any number of values and/or comments. This allows
     for combinations of values (i.e. AND/OR) - see the notes on the value element for
     additional information.
-->
<!ELEMENT attribute  (value | comment)*>
<!ATTLIST attribute  character   CDATA #REQUIRED>

<!-- A list of zero or more attributes. 
-->
<!ELEMENT attribute-list (attribute)*>

<!-- The name of a item. Can be plain text, with optional comments.
-->
<!ELEMENT item-name  (#PCDATA | comment)*>

<!-- A DELTA item. An item consists of an item-name, an optional attribute
     list, and possibly an image which further describes that item. An item
     may have an identifier (itemid) which if provided should uniquely
     identify it within a document.

     DELTA 'multi-item taxa' are modelled by allowing an item to refer
     to another item. In this case the multi attribute should have a value
     equal to the itemid of the main taxon.

     For example. if itemB is derived from itemA, then we could express this as:

     <item item="A"><item-name>itemA</item-name></item>
     <item item="B" multi="A"><item-name>itemB</item-name></item>

     There is no need to group the items of a mult-item taxon together.

     TODO - should attribute list be optional? A list can already contain
     zero attributes?

     TODO - should an item allow an image-ref as well as an image? Could
     be alternates.

-->
<!ELEMENT item (item-name, attribute-list?, image?)>
<!ATTLIST item  itemid    CDATA     #IMPLIED
                multi     CDATA     #IMPLIED>

<!-- A list of zero or more items.
-->
<!ELEMENT item-list  (item)*>

<!-- The description of an XDELTA data set. Can be plain-text with optional
     embedded comments. -->
<!ELEMENT description (#PCDATA | comment)*>


<!-- An XDELTA document. An XDELTA document consists of an optional
     description followed by optional character and item-lists. The
     revision date for the document can be supplied as an attribute.

     This means that a document can be constructed in a very flexible
     way with characters and items being added as required.

     TODO - what other meta data do we need to hold about a document?
     Author? Authorities? Research grant data? This kind of information
     could be referenced from elsewhere perhaps using RDF? Check the
     feasibility of this.

     TODO - is this content model too loose? It does allow a data set to
     be built incrementally (e.g. characters first, followed by items),
     which is useful.

     TODO - its feasible that documents may grow quite lengthy with
     large datasets and users may prefer to hold character and item
     descriptions in separate documents. The item document can then
     refer to a main document which describes the characters. This might
     facilitate collaborative working as a centrally located document
     describing common characters could be referenced by several teams.
     In this case the semantics of importing other character lists should
     be defined - i.e. how inter-document references are managed, and
     how conflicting/over-riding character descriptions should be dealt
     with by applications.
     
-->
<!ELEMENT xdelta (description?, character-list?, item-list?)>
<!ATTLIST xdelta revised        CDATA #IMPLIED>


<!-- 
      ====================================================================
                               END OF FILE

      ====================================================================
-->