Examples of XML Dictionary Usage1
John I. Bobbitt
POSC
License Agreement: © 2004, Petrotechnical Open Standards Consortium, Inc. All rights reserved. All access, receipt, and/or use of this document is subject to the POSC Product Licensing Agreement posted on the POSC Web site at http://www.posc.org/about/license.shtml.
Abstract: A dictionary is a resource of referenceable XML instances that can be accessed by XML applications. An XML instance document can reference the dictionary, and not have to worry about recording all the information in the XML document itself. The key to using a dictionary is to be able to access the information at read time, and extract the data that is needed.
A dictionary2 is a convenient way to collect a set of “standard” referenceable information. Examples of dictionaries would be a collection of coordinate reference systems, a collection of business associates, units of measure definitions, and name-description pairs of reference data. Examples of each of these will be shown, and a discussion of referencing them will be given.
The common properties of a dictionary are
A dictionary is separate from the XML application document3.
A dictionary need not be an XML document itself, but it must be accessible by an XML request, and must be able to “return” an XML document to the requester.
A dictionary must have a known structure, although different dictionaries may have different structures. That is, when a reader requests a particular dictionary, its structure should be known to the reader.
Any important instance of a dictionary should be accessible to the requester. That is, there should be a key that the requester can use to access a particular node of the dictionary.
The implementation of a dictionary is not specified. The only requirement is that a given URL and/or a key will lead the requester to a proper node.
In practice, an application document should be able to insert a properly formed URL that can lead a reader to a particular node in an XML structure.
Caution: It should be noted that an XML file can reference a dictionary item by name (or symbol or ID). But in order that it can be used, the file must also point to the dictionary that contains the name. This paper assumes that the file will also include, in some manner, a reference to the dictionary.
Below are four examples of dictionaries that will be used in the rest of the paper.
A measurement is characterized by its accuracy. One scheme for expressing the accuracy is to give one of the following list: {‘0.3 m’, ‘3 m’, ’15 m’, ’30 m’, ’90 m’, ‘150 m’, ‘300 m’, ‘800 m’, ‘above 800 m’}. It may be useful for the person receiving a document that has one of these values to find out the meaning of the value. For example, a location can be given with a lat/lon value, and the accuracy expressed as ’30 m’.
It is always possible that the writer of the document has included a section that gives the meaning of this value. In general, though, the writer simply gives the value, and expects the reader to know or find the meaning of it.
Here is a bit of this dictionary:
<EnumeratedList>
<Name>Location Accuracy Type</Name>
<NamingSystem>PEER</NamingSystem>
<Version>1.0</Version>
<Value>
<Name>0.3 m</Name>
<NamingSystem>Pilot</NamingSystem>
<Description>Accuracy to the nearest foot (.3 m)</Description>
<Source>PEER</Source>
<LastUpdated>2003-02-15</LastUpdated>
</Value>
<Value>
<Name>3 m</Name>
<NamingSystem>Pilot</NamingSystem>
<Description>Accuracy to within 10 feet (3 m)</Description>
<Source>PEER</Source>
<LastUpdated>2003-02-15</LastUpdated>
</Value>
<Value>
<Name>15 m</Name>
<NamingSystem>Pilot</NamingSystem>
<Description>Accuracy to within 50 feet (15 m)</Description>
<Source>PEER</Source>
<LastUpdated>2003-02-15</LastUpdated>
</Value>
. . .
</EnumeratedList>
This is a very simple dictionary structure. It is the purpose of the reader of the XML file to a) access this XML file, b) go to the Value node whose Name = ’30 m’, and print out (or otherwise access) the Description.
When sending information about something, it is very useful, and very often the case, to include a ‘Contact.’ A Contact represents a business associate – name, phone numbers, email, address, company, etc. As a practice, an XML application would prefer to send a “key” value, and rely on the receiver of the file to fill in the rest of the information. For example, a file might have Contact = ‘Joe Bleaux’. It is expected that the receiver could then determine the phone number, etc. of Joe Bleaux if he needs to contact him.
One way of doing this, of course, is to send the full set of information about any such business associate. Another way is to record this information in an XML dictionary and let the receiver reference it by using the key, ‘Joe Bleaux.’
Here is an example of a “contacts” database, expressed as an XML dictionary file.
<?xml version="1.0"?>
<BusinessAssociateDictionary
xmlns="http://www.cosmos.org"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<DocumentInformation>
<Name>Pilot Business Associate Dictionary</Name>
<Date>2003-02-28</Date>
<Security namingSystem="PEER">partner restricted</Security>
<Disclaimer>This dictionary is intended for demonstration purposes only. User's may freely access it. No guarantee is given for its accuracy.</Disclaimer>
</DocumentInformation>
<BAssoc id="joebleaux">
<ID>Joe Bleaux</ID>
<CodeSpace>Pilot</CodeSpace>
<Name>Joe Bleaux</Name>
<Type>person</Type>
<StreetAddress line="1">Suite 1220</StreetAddress>
<StreetAddress line="2">830 Chartres St.</StreetAddress>
<City>New Orleans</City>
<State>LA</State>
<PostalCode>61003</PostalCode>
<Country>US</Country>
<PhoneNumber type="voice">509-255-1234</PhoneNumber>
<PhoneNumber type="fax">509-255-4321</PhoneNumber>
<Email>joebleaux@tulane.edu</Email>
<AssociatedWith>Tulane Univ</AssociatedWith>
</BAssoc>
<BAssoc id="tulane">
<ID>Tulane Univ</ID>
<CodeSpace>Pilot</CodeSpace>
<Name>Tulane University</Name>
<Type>university</Type>
<StreetAddress line="1">Suite 100</StreetAddress>
<StreetAddress line="2">830 Chartres St.</StreetAddress>
<City>New Orleans</City>
<State>LA</State>
<PhoneNumber type="voice" qualifier="reception">800-TULANEU</PhoneNumber>
<Contact>Joe Bleaux</Contact>
</BAssoc>
</BusinessAssociateDictionary>
This dictionary contains only two entries – entries that are related to one another. When an XML application gives the value, Contact=”Joe Bleaux”, the reading application will need to access this dictionary, find the BAssoc node whose ID is ‘Joe Bleaux’, and print out the appropriate information about him. It can also find out that he is associated with another entry in the list, and should be able to access that information.
The third example is the units of measure dictionary. While a community of users can (and should) agree on a set of symbols to use for units of measure, it is also possible to store this information – and conversion factors – in a separate dictionary that can be accessed by the readers4. This is particularly useful if the data is to be accessed in the distant future (eg, 5 years from now) when memory of the meaning of a unit symbol has been forgotten.
There will always be cases of units that are not in a particular vocabulary. For example, California has some data in varas, which is generally not in standard lists. This unit can either be defined within the file, or referenced in a dictionary (since there are seven different varas, the referencing can point to the particular one that is being used).
Another case is the use of an unfamiliar symbol such as the ‘gAPI’. This unit (API gravity – a measure of density applied to oil) is defined in a dictionary and can be used. In another case, the symbol, ‘GLM’, was used for a length. A dictionary can resolve that to be the German Legal Metre, and give a conversion factor to a standard metre.
There is also the issue of unit symbols that are ambiguous. The use of ‘nm’ has been variously interpreted to be a nanometre, a nautical mile, and a newton metre.
A unit of measure symbol can be resolved by referencing a dictionary. The dictionary will give the symbol, and its meaning. The reading application can then be certain that it understands the meaning of the unit.
Here is an example of a unit of measure dictionary:
<?xml version="1.0"?>
<pr:UnitOfMeasureDictionary
xmlns:pr="http://www.posc.org/apps"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.posc.org/schemas"
xsi:schemaLocation="http://www.posc.org/apps
http://www.posc.org/appSchema/unitDict10.xsd">
<pr:UnitsDefinition>
<pr:UnitOfMeasure id="m" annotation="m">
<Name>metre</Name>
<CatalogName>POSC</CatalogName>
<CatalogSymbol isExplicit="True">m</CatalogSymbol>
<BaseUnit>
<Description>The metre is the length equal to 1 650 763.73 wavelengths in vacuum of the radiation corresponding to the transition between the levels 2p10 and 5d5 of the krypton-86 atom.</Description>
<BasicAuthority>ISO 1000</BasicAuthority>
</BaseUnit>
</pr:UnitOfMeasure>
<pr:UnitOfMeasure id="ftUS" annotation="ftUS">
<Name>US Survey Foot</Name>
<CatalogName>POSC</CatalogName>
<CatalogSymbol isExplicit="True">ftUS</CatalogSymbol>
<ConversionToBaseUnit baseUnit="#m">
<Fraction>
<Numerator>12</Numerator>
<Denominator>39.37</Denominator>
</Fraction>
</ConversionToBaseUnit>
</pr:UnitOfMeasure>
<pr:UnitOfMeasure id="ftBnA" annotation="ftBnA">
<Name>British Foot (Benoit 1895 A)</Name>
<CatalogName>POSC</CatalogName>
<CatalogSymbol isExplicit="True">ftBnA</CatalogSymbol>
<ConversionToBaseUnit baseUnit="#m">
<Fraction>
<Numerator>.9143992</Numerator>
<Denominator>3</Denominator>
</Fraction>
</ConversionToBaseUnit>
</pr:UnitOfMeasure>
. . .
</pr:UnitsDefition>
</pr:UnitOfMeasureDictionary>
The goal that we will accomplish is shown as follows. Assume I have a value in an XML file:
<MeasuredDepth uom=”ft”>136.2</MeasuredDepth>
The reading file will use a dictionary to convert that value into a base unit (metres) and print out the value in metres. To do this, I need to tell the reader what kind of foot I mean by ‘ft’, to go to the dictionary, find the appropriate kind of foot, read the conversion information, and apply the conversion. This example is mostly to show that we can effectively use a dictionary for calculations.
When a location is given, it is necessary to give the coordinate reference system (CRS) that defines the location. For example, a lat/lon value can differ by a ground position by several metres depending on whether the CRS is NAD27, NAD83, or WGS 84. In addition, a conversion of this data to a map projection (such as UTM 14N) requires that this datum be known.
There is a lot of information that goes with a CRS. However, a writer should only need to specify the CRS by a standard name, and let a dictionary give the rest of the information. The purpose of a standard dictionary is to allow a reading application (such as a map plotting package) to determine the additional information that is hidden behind the name.
This example may seem to be like the rest. But it is different in an important aspect. There is a service that has a specified API call that will return an XML file to the caller. Behind this service is not a large, XML dictionary of CRS’s. Instead, the data is kept in a database5. Only when a caller requests a CRS does the data get written to an XML file that is then presented to the requester.
This figure is a screen that is the user interface for the CRS database. It can be accessed at http://crs.opengis.org/crsportal/index.html. But accessing it does not give the data to you in a usable format. When you call it with the following http:
you will get an XML file retuned. Here is the XML file:
<?xml version="1.0" encoding="UTF-8"?>
<GetResourceByIDResponse xmlns="http://www.opengis.net/wrs">
<gml:GeographicCRS xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" gml:id="urn:epsg:v6.1:coordinateReferenceSystem:4326">
<ogc:commonMetaData>
<ogc:CommonMetaData>
<ogc:informationSource />
<ogc:dataSource>EPSG</ogc:dataSource>
<ogc:revisionDate>6/2/1995</ogc:revisionDate>
</ogc:CommonMetaData>
</ogc:commonMetaData>
<ogc:crsMetaData>
<ogc:CRSMetaData>
<ogc:showCRS>-1</ogc:showCRS>
</ogc:CRSMetaData>
</ogc:crsMetaData>
<ogc:validAreaMetaData xmlns:xlink="http://www.w3.org/1999/xlink">
<ogc:ValidAreaMetaData>
<ogc:name>World</ogc:name>
<ogc:areaOfUse>World.</ogc:areaOfUse>
<ogc:isoA2Code />
<ogc:isoA3Code />
<ogc:isoNCode />
<ogc:remarks />
<ogc:informationSource>EPSG</ogc:informationSource>
<ogc:dataSource>EPSG</ogc:dataSource>
<ogc:revisionDate>6/5/2001</ogc:revisionDate>
</ogc:ValidAreaMetaData>
</ogc:validAreaMetaData>
<gml:crsID>
<gml:code>4326</gml:code>
<gml:name>WGS 84</gml:name>
<gml:remarks />
<gml:scope>Used by the GPS satellite navigation system and for NATO military geodetic surveying.</gml:scope>
</gml:crsID>
<gml:usesCoordinateSystem>
<gml:EllipsoidalCS xmlns="http://www.opengis.net/ogc" gml:id="urn:epsg:v6.1:coordinateSystem:6402">
<ogc:commonMetaData>
<ogc:CommonMetaData>
<ogc:informationSource>EPSG</ogc:informationSource>
<ogc:dataSource>EPSG</ogc:dataSource>
<ogc:revisionDate>1/19/2001</ogc:revisionDate>
</ogc:CommonMetaData>
</ogc:commonMetaData>
<ogc:csMetaData>
<ogc:CSMetaData>
<ogc:dimension>2</ogc:dimension>
</ogc:CSMetaData>
</ogc:csMetaData>
<gml:csID>
<gml:code>6402</gml:code>
<gml:name>Ellipsoidal 2D CS. Axes: latitude, longitude. Orientations: east, north. UoM: DMSH.</gml:name>
<gml:remarks>Used in geographic 2D coordinate reference systems.</gml:remarks>
</gml:csID>
<gml:usesAxis xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="urn:epsg:v6.1:coordinateAxis:44" />
<gml:usesAxis xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="urn:epsg:v6.1:coordinateAxis:45" />
</gml:EllipsoidalCS>
</gml:usesCoordinateSystem>
<gml:usesDatum>
<gml:GeodeticDatum xmlns="http://www.opengis.net/ogc" gml:id="urn:epsg:v6.1:datum:6326">
<ogc:CommonMetaData>
<ogc:informationSource />
<ogc:dataSource>EPSG</ogc:dataSource>
<ogc:revisionDate>6/2/1995</ogc:revisionDate>
</ogc:CommonMetaData>
<ogc:datumMetaData>
<ogc:DatumMetaData>
<ogc:OriginDescription>Origin at geocentre.</ogc:OriginDescription>
</ogc:DatumMetaData>
</ogc:datumMetaData>
<ogc:validAreaMetaData xmlns:xlink="http://www.w3.org/1999/xlink">
<ogc:ValidAreaMetaData>
<ogc:name>World</ogc:name>
<ogc:areaOfUse>World.</ogc:areaOfUse>
<ogc:isoA2Code />
<ogc:isoA3Code />
<ogc:isoNCode />
<ogc:remarks />
<ogc:informationSource>EPSG</ogc:informationSource>
<ogc:dataSource>EPSG</ogc:dataSource>
<ogc:revisionDate>6/5/2001</ogc:revisionDate>
</ogc:ValidAreaMetaData>
</ogc:validAreaMetaData>
<gml:datumID>
<gml:code>6326</gml:code>
<gml:name>World Geodetic System 1984</gml:name>
<gml:alias>
<gml:aliasName>WGS 84</gml:aliasName>
<gml:aliasNameSpace>EPSG abbreviation</gml:aliasNameSpace>
<gml:aliasRemarks />
</gml:alias>
<gml:remarks>Datum code 6327 reserved for southern hemisphere ProjCS's</gml:remarks>
<gml:scope>Satellite navigation.</gml:scope>
</gml:datumID>
<gml:realizationEpoch>1984</gml:realizationEpoch>
<gml:usesPrimeMeridian xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="urn:epsg:v6.1:primeMeridian:8901" />
<gml:usesEllipsoid xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="urn:epsg:v6.1:ellipsoid:7030" />
</gml:GeodeticDatum>
</gml:usesDatum>
</gml:GeographicCRS>
</GetResourceByIDResponse>
This file is now available to us as an XML file to save or to extract the needed information to more fully understand the CRS. Note that it is not saved or archived, it is obtained as a virtual file that only exists electronically during its usage. The purpose of this example is to show that a dictionary file can exist as a service, with a database as a backend.
For the dictionary concept to work, the writer must include the dictionary location in the XML file itself in a way that is known to the reader. In addition, the reader must be able to use this information to access the dictionary and the particular value that is in the dictionary.
There are several ways to declare the dictionary. I will not bother to go into them, except to give an example, and show how it works. All the examples will be based on the objective of taking a simple XML output, and printing out (on the screen) the information about it. This will be done using an XSL file, which is used to format the data for the browser.
The XML file in question is as follows:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="../xsl/cosmosN.xsl"?>
<PilotProjectData
xmlns="http://www.peer.org/cosmos"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.posc.org/schemas
http://www.posc.org/cosmos/site.xsd">
<Site id="arl">
<ID>ARL</ID>
<Name>Arleta</Name>
<CodeSpace>ROSRINE</CodeSpace>
<Contact>Joe Bleaux</Contact>
<Location>
<CRS href="wgs84">WGS 84</CRS>
<LatitudeValue uom="deg">34.236</LatitudeValue>
<LongitudeValue uom="deg">-118.44</LongitudeValue>
</Location>
<LocationMethod>DGPS</LocationMethod>
<LocationAccuracy>800 m</LocationAccuracy>
</Site>
<Hole id="arl3">
<ID>ARL_3</ID>
<SiteID href="arl">ARL</SiteID>
<Logger>Tulane Univ</Logger>
<Depth uom="ft" qualifier="Logger">490</Depth>
</Hole>
<BusinessAssociateDictionary>bAssocExample.xml</BusinessAssociateDictionary>
<LocationAccuracyDict>locationAccuracy.xml</LocationAccuracyDict>
<RemoteReference id="ft" href="http://www.posc.org/refs/poscUnits.xml#ftUS"/>
<CRSDictionary>http://www.posc.org/schemas/cosmos/crsDict.xml</CRSDictionary>
</PilotProjectData>
The file is intentionally kept short and simple in order to deal with the dictionary issues.
Note that the information is contained in the Site and Hole elements. The four elements at the end are pointers to dictionaries. Also note that a stylesheet is referenced for viewing the data. This stylesheet will in practice vary as the four examples are given. (N will vary from 0...4).
The stylesheet shown below prints out some of the information in the file in an HTML file for viewing. This is shown as the base case that uses only the information in the file itself to gather and display the information. This is stylesheet cosmos0.xsl6.
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:p="http://www.posc.org/schemas"
xmlns:app="http://www.peer.org/cosmos"
xmlns="http://www.w3.org/TR/xhtmll/strict">
<xsl:template match="/">
<HTML>
<HEAD>
<TITLE>Example of Ref Data</TITLE>
</HEAD>
<BODY>
<xsl:apply-templates select="//app:Site"/>
<xsl:apply-templates select="//app:Hole"/>
<P><SMALL>Translator developed by POSC</SMALL></P>
</BODY>
</HTML>
</xsl:template>
<xsl:template match="app:Site">
<H1>Site Information</H1>
<P>This will print out only the basics. The important info is in other files, and will be dealt with later.</P>
<P>Site Name: <xsl:value-of select="app:Name"/></P>
<P>Contact: <xsl:value-of select="app:Contact"/></P>
<P>Location is:<UL>
<LI>Latitude: <xsl:value-of select="app:Location/app:LatitudeValue"/> <xsl:value-of select="app:Location/app:LatitudeValue/@uom"/></LI>
<LI>Longitude: <xsl:value-of select="app:Location/app:LongitudeValue"/> <xsl:value-of select="app:Location/app:LongitudeValue/@uom"/></LI>
<LI>Location Accuracy: <xsl:value-of select="app:LocationAccuracy"/></LI>
</UL></P>
</xsl:template>
<xsl:template match="app:Hole">
<H1>Hole data</H1>
<P>Will only do the Logger and depth. Later will interpret the unit of measure</P>
<P>Logger: <xsl:value-of select="app:Logger"/></P>
<P>Depth: <xsl:value-of select="app:Depth"/> <xsl:value-of select="app:Depth/@uom"/></P>
</xsl:template>
</xsl:stylesheet>
The following diagram shows how the stylesheet prints out the data:
The reference data is in the file, locationAccuracy.xml, as shown in section 2.1. For this example, we only want to be informative, in the sense that we will display the meaning of the Location Accuracy: 800 m that is shown above.
Here is the stylesheet, cosmos1.xsl, with the new values (other than comments) in red.
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:p="http://www.posc.org/schemas"
xmlns:app="http://www.peer.org/cosmos"
xmlns="http://www.w3.org/TR/xhtmll/strict">
<!--Up front you must declare the keys. The dictionary contains object nodes,
with id's. -->
<!--The purpose of this stylesheet is to illustrate the method of accessing a simple
ref data file, and printing the description along with the value
The dictionary must be given in the file, and the key is the value of the element.
-->
<xsl:key name="refkey" match="Value" use="Name"/>
<xsl:template match="/">
<HTML>
<HEAD>
<TITLE>Example of Ref Data</TITLE>
</HEAD>
<BODY>
<xsl:apply-templates select="//app:Site"/>
<xsl:apply-templates select="//app:Hole"/>
<P><SMALL>Translator developed by POSC</SMALL></P>
</BODY>
</HTML>
</xsl:template>
<xsl:template match="app:Site">
<H1>Site Information</H1>
<P>This will print out only the basics. The important info is the description of the location accuracy, which is not in the file.</P>
<P>Site Name: <xsl:value-of select="app:Name"/></P>
<P>Contact: <xsl:value-of select="app:Contact"/></P>
<P>Location is:<UL>
<LI>Latitude: <xsl:value-of select="app:Location/app:LatitudeValue"/> <xsl:value-of select="app:Location/app:LatitudeValue/@uom"/></LI>
<LI>Longitude: <xsl:value-of select="app:Location/app:LongitudeValue"/> <xsl:value-of select="app:Location/app:LongitudeValue/@uom"/></LI>
<LI>Location Accuracy: <xsl:value-of select="app:LocationAccuracy"/>
<BR/>which means:
<xsl:call-template name="printReference">
<xsl:with-param name="reference" select="app:LocationAccuracy"/>
<xsl:with-param name="keytype" select="'refkey'"/>
<xsl:with-param name="dictionary" select="/*/app:LocationAccuracyDict"/>
</xsl:call-template>
</LI>
</UL></P>
</xsl:template>
<xsl:template match="app:Hole">
<H1>Hole data</H1>
<P>Will only do the Logger and depth. Later will interpret the unit of measure</P>
<P>Logger: <xsl:value-of select="app:Logger"/></P>
<P>Depth: <xsl:value-of select="app:Depth"/> <xsl:value-of select="app:Depth/@uom"/></P>
</xsl:template>
<xsl:template name="printReference">
<xsl:param name="reference"/>
<xsl:param name="keytype"/>
<xsl:param name="dictionary"/>
<xsl:apply-templates select="document($dictionary)/*">
<xsl:with-param name="reference" select="$reference"/>
<xsl:with-param name="keytype" select="$keytype"/>
</xsl:apply-templates>
</xsl:template>
<xsl:template match="EnumeratedList">
<xsl:param name="reference"/>
<xsl:param name="keytype"/>
<xsl:apply-templates select="key($keytype,$reference)"/>
</xsl:template>
<xsl:template match="Value">
<xsl:value-of select="Description"/>
</xsl:template>
</xsl:stylesheet>
The purpose of this is not to train you in stylesheet development. The purpose is to show that dictionaries can be accessed quite readily. The above stylesheet will be briefly described below.
The line near the top says to use the Value/Name as a key. Within the part that prints out the Site information, there is a “call” to a template that will do the work (this is where the new information will be printed).
The PrintReference template opens the dictionary document using the document(.) command. Since this open puts us at the EnumeratedList element7, we go to the template for EnumeratedList. The key(.) function is used to put us at the proper Value element. Once there, we use the value-of command to print the Description.
The result of all of this is a lot of movement, but only a single “print” statement. When put into a browser, the result is:
The only difference between this and the previous is the line, “which means: Accuracy to within one-half mile (800 m)”. While this is not a profound difference, it does illustrate that it is possible to extract information from an outside dictionary.
Once in a dictionary file, it is possible to reference data that is referenced within the file. That is, the referencing mechanism is not limited to simply going to a value in another file. It can get as complicated as you wish.
For this example, the business associate dictionary will be referenced to print out information about the Site.Contact, Joe Bleaux, and the Logger, Tulane Univ. The simple example has each of these referencing each other (just to keep the files small). In general, any instance that is referenced can be reached.
Of the information included in the file (see section 2.2), I will print out Joe Bleaux’s Name, phone number, fax number and email. I will then print out who he is associated with, and the address of the associated group (Tulane University). This is simply to demonstrate that it is possible to wander around the dictionary file to pull off appropriate information.
The stylesheet will not be printed in this document. It will be available as a separate file for those who are interested in it.
and...
The printed information for these two entries is not very sophisticated, but they do indicate that information is pulled from various places in the Business Associate file.
In addition to simply printing informative information, the data in a file can be used to process information. The next example will build on the example in section 3.2 (ie, the information about the business associates will not be included, in order that the file not get too long).
The unit of measure reference in the basic XML document is
<Depth uom="ft" qualifier="Logger">490</Depth>
In theory, the symbol “ft” contains no information. We can guess that it means a “foot”, but which foot? And does it really mean foot?
This can be resolved with the dictionary reference at the end of the file:
<RemoteReference id="ft" href="http://www.posc.org/refs/poscUnits.xml#ftUS"/>
This reference says to go to the document ‘http://www.posc.org/refs/poscUnits.xml’ and look up the instance referenced with ‘ftUS’. This instance (as shown in section 2.3) gives the meaning of this unit, as well as its conversion parameters. The stylesheet will go to the site, and apply the conversion to metres.
A CRS is a very complicated object. A full description of it based on the ISO 19115 standard includes definitions of the datum, ellipsoids, prime meridian, possibly some transformations or conversions, and information about the axes. There are standard dictionaries which include this information.
Rather than having the writing application record all of this information each time it gives a lat/lon or a UTM description, it is possible to give a standard CRS name, and, if the reading application needs it, find the resource that contains the additional information.
This is not straightforward. Giving the URL to the resource would unnecessarily tax the XML writers. For example, the URL that produces the XML output that is shown in section 2.4 is
Rather than require that long string, we can require a simple name: ‘WGS 84’.
The leads to a two-step process.
The first step is to give a list of standard names to the writers. Examples for lat/lon systems would be ‘NAD27’, ‘NAD83’, ‘WGS 72’, and ‘WGS 84’. In North America, it is doubtful that any other values would be used.
Develop a CRS dictionary XML that would map this name to the URL.
The writer would only need to include something like
<CRS>WGS 84</CRS>
in the XML file, along with a reference to the CRS dictionary:
<CRSDictionary>http://www.posc.org/schemas/cosmos/crsDict.xml</CRSDictionary>
The reader would open the dictionary, find the URL call, and apply that to obtain the CRS definition file from the ISO standard dictionary.
Here is a portion of a CRS dictionary:
<?xml version="1.0"?>
<CRSDictionary
xmlns="http://www.peer.org/cosmos"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<DocumentInformation>
<Name>Pilot Coordinate Reference System Dictionary</Name>
<Date>2003-02-28</Date>
<Security namingSystem="PEER">wide open</Security>
<Disclaimer>This dictionary is intended for demonstration purposes only. User's may freely access it. No guarantee is given for its accuracy.</Disclaimer>
<Comment>The URLs point to a temporary portal, which is due to change in the near future.</Comment>
</DocumentInformation>
<CRS id="wgs84">
<ID>WGS 84</ID>
<CodeSpace>Pilot</CodeSpace>
<Name>World Geodetic System 1984</Name>
<NamingSystem>EPSG Full Name</NamingSystem>
<EPSGCode>4326</EPSGCode>
<URL>http://dali.galdosinc.com/registry/wrs?request=getResourceByID&id=urn:epsg:v6.1:coordinateReferenceSystem:4326</URL>
<Type>geographic</Type>
</CRS>
</CRSDictionary>
This type of dictionary is sometimes referred to as a “skip resource.” This is in analogy to rock skipping, in which a rock hits the water, and skips to another place. A reference to this dictionary is skipped directly to another resource.
This example is also being presented to show that the final resource need not be an XML file. In actual practice, the resource is a database, but a call using the prescribed URL returns an XML file. I.e., it is a database that can look like an XML file.
The stylesheet that was applied prints out the first line of CRS from the CRS dictionary, and the second from information that is buried in the URL location. This information can be found in the XML in section 2.4
[ANSIX12] X12 Reference Model for XML Design, 2002-10, produced by the ANSI X12 committee, obtainable at http://www.x12.org/x12org/.
[BestPractices] Best Practices Homepage, developed and maintained by XML-dev and Mitre, obtainable at http://www.xfront.com/BestPracticesHomepage.html.
[ComProServ] PIDX XML Standards Master, Version 1.0, RP 3901, produced by PIDX, obtainable at http://committees.api.org/business/pidx/standards.htm.
[EBCCNAM] ebXML RT - Naming Convention for Core Component, 2001-05-10, produced by the ebXML group, obtainable at http://www.ebxml.org/specs/index.htm#technical_reports.
[ebTechArch] ebXML Technical Architecture Specification V1.0.4, 2001-02-16, produced by the ebXML group, obtainable at http://www.ebxml.org/specs/ebTA.pdf.
[FedDevGuide] Draft Federal XML Developer's Guide, 2002-04 (work in progress), produced by the Federal CIO Council, obtainable at http://xml.gov/documents/in_progress/developersguide.pdf.
[FedTagStds] Federal Tag Standards for Extensible Markup Language, 2001-06, produced by LMI, not obtainable from the internet.
[HKGuide] XML Schema Design and Management Guide, (4 parts), Draft versions dated in summer, 2003. Produced by Hong Kong Information Services Technology Division. Available at http://www.itsd.gov.hk/itsd/english/infra/eif.htm.
[IETFKeywords] Key Words for Use in RFCs to Indicate Requirement Level, 1997-03, obtainable at http://www.ietf.org/rfc/rfc2119.txt.
[ISO8601] International Standard Date and Time, 2001-11-10, produced by ISO. A web page that explains the formats is http://www.cl.cam.ac.uk/~mgk25/iso-time.html.
[ISO11179] ISO 11179 Part 5 - Naming and Identification, 1995-12, produced by ISO, obtainable at http://fdr.faa.gov/iso/ISO11179page.htm. There is a later version, that is available from the ISO website,
[UKGuide] e-Government Schema Guidelines for XML, 2002-12, produced by United Kingdom e-Envoy, obtainable at http://www.e-envoy.gov.uk/Resources/Guidelines/fs/en.
[Unicode] Unicode Charts, available at http://www.unicode.org/charts/.
[W3CSchemaDatatypes] W3C Schema Datatypes, 2001-05-02, produced by W3C, obtainable at http://www.w3.org/TR/xmlschema-2.
[W3CNamespaces] Namespaces in XML, 1999-01-14, produced by W3C, obtainable at http://www.w3.org/TR/REC-xml-names/.
[W3CSchemaPrimer] W3C Schema Primer, 2001-05-02, produced by W3C, obtainable at http://www.w3.org/TR/xmlschema-0.
[W3CSchemaStructures] W3C Schema Structures, 2001-05-02, produced by W3C, obtainable at http://www.w3.org/TR/xmlschema-1.
[Xlink] W3C XLink Specification, 2001-06, produced by W3C, obtainable at http://www.w3.org/TR/xlink/.
[Xpath] W3C XPath Specification, 1999, produced by W3C, obtainable at http://www.w3.org/TR/xpath/.
[XSL] W3C XSL and XSLT Specifications, produced by W3C, obtainable at http://www.w3.org/Style/XSL/.
POSC references are available in the following formats:
[html] html format readable by browsers
[doc] MS Word 97/2000/XP
[sxw] OpenOffice writer, v1.0
[IntroModule] Introduction to Modules, Copyright 2002-2003. Available in [html], [doc], [sxw].
[BuildModule] Build a Module - a tutorial. Copyright 2003. Available in [html], [doc], [sxw].
[ImportModule] Importing Modules within your Modules. Copyright 2003. Available in [html], [doc], [sxw].
[Guidelines] Guidelines for XML Schemas, Version 2003. Copyright 2003. Available in [html], [doc], [sxw].
[ModulePolicies] Policies on Modules. Copyright 2002-2003. Available in [html], [doc], [sxw].
[ProfilesAppSchema] Modules, Profiles, and Application Schemas. Copyright 2002-2003. Available in [html], [doc], [sxw].
[XMLTables] XML Tables. Copyright 2003. Available in [html], [doc], [sxw].
[ReferenceData] Reference Data and Enumerated Lists Implemented in XML. Copyright 2002-2003. Available in [html], [doc], [sxw].
[Dictionaries] Examples of XML Dictionary Usage. Copyright 2003. Available in [html], [doc], [sxw]. Accompanied by sample code.
[Relationships] Relationships in XML. Copyright 2003. Available in [html], [doc], [sxw].
[UOMRecs] Unit of Measure Recommendations. Copyright 2002-2003. Available in [html], [doc], [sxw].
1© 2004, Petrotechnical Open Standards Consortium, Inc. All rights reserved. All access, receipt, and/or use of this document is subject to the POSC Product Licensing Agreement posted on the POSC Web site at http://www.posc.org/about/license.shtml.
2The term, registry, is often used to mean the same thing.
3 An XML application document is a document that transfers information. It transfers dictionary information by referencing a dictionary document.
4 To understand the importance of knowing what unit of measure is being used by a value, you need go no further than the Mars Lander. NASA specified the use of metric units, and Lockheed used English units. The Mars Lander crashed.
5 This approach is similar to the problem faced by many data providers. They physically have their data in a database, and only wish to convert it to an XML file when it is requested.
6 To view the xml file using the stylesheet, make sure the data file (the xml file) has cosmos1.xsl in line 2.
7 Yes, you do need to know the structure of the dictionary document to do this.