How to upgrade from ANZMETA DTD v1.1 to DTD v1.3


This document attempts to explain from the point-of-view of the XML document instances (the actual metadata records). Please also see the main ANZMETA DTD documentation and especially documentation for each DTD to explain the actual changes. This page is intended for technical readers who are metadata application developers. It is deliberately terse, assuming that you are familiar with the ANZMETA DTDs and with XML technologies in general.

It has become apparent that many metadata custodians did not upgrade to DTD v1.2 so this page is intended to facilitate the upgrade from Version 1.1 directly to the current Version 1.3 structure.

Two example XML instances were provided with the v1.3 documentation. Please use those as examples of the final result. This "How to upgrade" document concentrates on the necessary changes to achieve a v1.3 XML instance.

New document type declaration

Declare the new Document Type Definition. Simply change the top of the XML instance to this ...

<!DOCTYPE anzmeta PUBLIC "-//ANZLIC//DTD ANZMETA 1.3//EN"
 "http://www.auslig.gov.au/dtd/anzmeta-1.3.dtd">

Optional "thesaurus" attribute for all <keyword> elements

Each <keyword> can have an optional "thesaurus" attribute to show which authority list is relevant. All authority lists (i.e. controlled vocabularies) were provided with the v1.2 documentation.

Example with using the thesaurus attribute ...

<jurisdic>
  <keyword thesaurus="anzlic-jurisdic">
    Australia
  </keyword>
</jurisdic>

Example without using the thesaurus attribute ...

<jurisdic>
  <keyword>Australia</keyword>
</jurisdic>

The "thesaurus" attribute can be used with all <keyword> elements (e.g. theme, place, begdate, enddate, etc.) to declare the relevant authority list.

Two container elements that were optional are now mandatory

The elements <spdom> (Spatial Domain) and <distinfo> (Access) are now mandatory.

Different structure within <spdom>

As you know, the Spatial Domain of a dataset can be defined using a number of <place> elements. Each <place> can hold either a Geographic Extent Name (i.e. a <keyword> element) or Geographic Extent Polygon (i.e. a <dsgpolyo> elements). The internal structure has changed for both situations, as described in the following sections.

Add <vertex> containers within <dsgpolyo>

Here is an example for DTD v1.1 ...

    <spdom>
      <place>
        <dsgpolyo>
          <long>150.67</long>
          <lat>-35.05</lat>
          <long>150.675</long>
          <lat>-35.04</lat>
          <long>150.68</long>
          <lat>-35.05</lat>
          <long>150.675</long>
          <lat>-35.06</lat>
          <long>150.67</long>
          <lat>-35.05</lat>
        </dsgpolyo>
      </place>
      ...
      ...

Here is the same example as v1.3 ...

    <spdom>
      <place>
        <dsgpolyo>
          <vertex>
            <long>150.67</long>
            <lat>-35.05</lat>
          </vertex>
          <vertex>
            <long>150.675</long>
            <lat>-35.04</lat>
          </vertex>
          <vertex>
            <long>150.68</long>
            <lat>-35.05</lat>
          </vertex>
          <vertex>
            <long>150.675</long>
            <lat>-35.06</lat>
          </vertex>
          <vertex>
            <long>150.67</long>
            <lat>-35.05</lat>
          </vertex>
        </dsgpolyo>
      </place>
      ...
      ...

Add attributes to <place><keyword> elements

Each Geographic Extent Name (GEN) is represented as a <keyword> element within a <place> container element. The DTD v1.3 adds some new attributes to a keyword element, so as to facilitate the proper definition of a GEN. Please refer to the current ANZLIC Metadata Guidelines (version 2) for the full explanation of the GEN structure and the allowable values for the new GEN attributes.

Here is an example for DTD v1.1 ...

      <spdom>
         <place>
            <keyword thesaurus="MAP-1000">
               SYDNEY (SI56) 1:100 000 000 Map Sheet
            </keyword>
         </place>
         ...
         ...

Here is another example for DTD v1.1 ...

      <spdom>
         <place>
            <keyword thesaurus="100K Map Sheet">
               JERVIS BAY,New South Wales,9027
            </keyword>
         </place>
         ...
         ...

Note that the lack of attributes meant that the metadata custodians tried to express the GEN as un-structured content. The content could not be interpreted by a parser or stylesheet, so the final output is not useful. Note also that there is inconsistency between the two custodians in their use of the GEN capability.

Here is the same example as v1.3 ...

    <spdom>
      <place>
        <keyword thesaurus="1:100 000 Map Series" identifier="9027"
                 custodian="Australia">
          JERVIS BAY
        </keyword>
      </place>
      ...
      ...

This more complete information now helps to define a GEN properly, and so can now be readily used when applying a stylesheet to an XML instance.

Use the Geographic Extent Name lists from "GEN Register"

The Geographic Extent Name (GEN) Register holds the official authority lists. The GEN Register also explains how to compose a Geographic Extent Name.

Here is a summary of how the attributes of the <keyword> element are used to describe a GEN ...

The thesaurus attribute is consistent with the rest of the DTD. It defines the authority list (controlled vocabulary) to be used. The allowed values come from the GEN Register list called "GEN Category" (anzlic-gencategories.txt).

The identifier attribute is obvious. Its value would probably be a unique identifier within the associated thesaurus/category.

The custodian attribute is the "GEN Custodial Jurisdiction" i.e. the "Country, state or territory that is responsible for maintaining the detail of the geographic object" This concept is explained by the ANZLIC Metadata Guidelines (version 2). The allowed values are defined in the Metadata Guidelines.

Of course, the content of the keyword element (e.g. JERVIS BAY) is the actual GEN Name itself.

Towards reliable XML

That is all of the changes. Now do not forget to use a validating XML parser to ensure that your final XML instances do in fact comply with the DTD v1.3