Status of PEF XML:
This is the first notice of this document. It is a request to send questions and comments to POSC.
Based on previous comments, it is anticipated that there will be changes and additions to the document. For those wishing to implement any of the recommendations, it is expected that the stable parts are:
Mapping of instances
Mapping of attributes
Referencing of units.
Mapping of the following datatypes:
integer, real, string, boolean, logical, binary, enumeration, aggregates, complex, rational, ratio, money, quantity, location.
The following are open questions:
The PEF Header is modelled using the exchange objects from previous versions of Epicentre. This is basically metadata describing the data being exchanged. It is expected that this header will change considerably over the next few years, as standard metadata models are developed.
Please send comments to bobbitt@posc.org.
The Epicentre XML Exchange Format is based on the Express Specification of the Epicentre Data Model. This document will explain the mapping from the Express entities, attributes, and data types into XML Elements and Attributes.
The purpose of defining an XML Exchange Format is to be able to exchange data based based on an Epicentre Data Model. It has been found that the PEF, based on RP66, is too burdensome for most exchanges. With the emergence of XML as an exchange format, it is useful to be able to express the data in this format.
The process described below is intended to be a method that will work for any version of an Epicentre data model. It consists of the following parts. (1) A mapping from Express entity names to XML Tag names. (2)A mapping from Express attribute names to XML Tag names. (3) A mapping from Express and Epicentre data types into XML structures. (4) The specification of a header comparable to the PEF objects as defined in the POSC Data Exchange Specification.
STEP has defined a method for mapping an Express data model into XML. This process was modified by Prism Tech, and a loader was developed for loading such data into an Epicentre 3.0 data base. The process was not complete, in that the definition of the XML structures for the "Frame" data types was never specified.
The results of this process are shown below. POSC, and various members, have deemed the resulting format to be too heavy for a data exchange format. Thus, parts of this mapping process were simplified in order to make the format lighter and more usable. Appendix A of this document gives an example of a geodetic datum using both mappings, along with some comments on the differences between the two.
In all cases, the data will be considered to be Epicentre data, based on a particular Epicentre data model. This does not imply that the data is actually kept in a data base that Epicentre compliant. However, it does imply that a step has been performed that maps the data into Epicentre instances that are represented (via the mapping below) in XML format.
Because both Express and XML use the same or similar terms, the following usage of these terms will be consistently applied followed throughout this document:
The mapping from Epicentre to XML will require mapping entity and attribute names into XML tags. The straightforward mapping is to use the Express name for the tag. There are two problems that are created by this process.
Various options for handling these problems have been considered. They are discussed below, and one is selected.
For entities, use the express entity name (such as ‘geodetic_datum’). For attributes, use the form, express entity name plus ‘.’ plus attribute name (such as geodetic_datum.ellipsoid). The attribute name has the entity name (of the leaf entity) prepended to it.
For example, the tag for geodetic_datum and some of its attributes are:
geodetic_datum geodetic_datum.description geodetic_datum.source geodetic_datum.identifier geodetic_datum.source_content geodetic_datum.source_reference geodetic_datum.status geodetic_datum.version geodetic_datum.naming_system geodetic_datum.ellipsoid geodetic_datum.prime_meridian
The advantage is that all entity and attribute tags are unique. Furthermore, the attribute tag is informative to the user. And the XML file is easy to generate given an Epicentre dictionary which groups all of the attributes of the leaf frame together. There are two main disadvantages. (1). The tag names are long, being a combination of entity and attribute names. (2). Inherited attributes are repeated over and over. For example, the attribute ‘description’ is inherited from e_and_p_data, and must be respecified for every leaf entity. Thus, the DTD becomes overly large.
The same as option 1, except the attributes are formed by prepending the names of the entity in which the attributes are defined. Here is the same list of attributes for the above example:
geodetic_datum e_and_p_data.description e_and_p_data.source technical_reference.identifier technical_reference.source_content technical_reference.source_reference technical_reference.status technical_reference.version aliasable_technical_reference.naming_system geodetic_datum.ellipsoid geodetic_datum.prime_meridian
The advantage is that the description attribute (for example) is specified only once, and is used as a subtag for all entity tags. Thus, the DTD is considerably smaller. However, the disadvantage is that it is hard to "guess" the tag name for an attribute – you must know the particular supertype which introduced it – unless you have some kind of dictionary file to aid you.
Use only the attribute name as the tag name. This would greatly shorten the names, and make it easier to form the XML. In order to distinguish between the (for example) ellipsoid as an entity tag and ellipsoid as an attribute tag, the entity tags would be formed in one of two ways. Either (3A) make the entity uppercase and the attributes lower case, or (3B) prepend (for example) EP to all entity names. Here is the same list using these rules:
GEODETIC_DATUM or EPgeodetic_datum description source identifier source_content source_reference status version naming_system ellipsoid prime_meridian
There are several advantages. Because of the prepend or the case, it is still easy to distinguish between entities and attributes. Also, the tag names are shorter, and will lead to a smaller DTD and XML file. The disadvantages are that we must specify how to handle case when referencing the data model and the express vs referencing the XML. Also, the 20 attributes that are repeated, but which are different data types, must be handled separately. Furthermore, the DTD begins to lose some of its specification properties if, for example, abandonment_date can be either a timestamp or a date.
Given the advantages and disadvantages of the above three options, we are choosing Option 3A. It is felt that smaller files, easier to generate, outweighs the disadvantage of a DTD that does not completely specify the data model. In particular, we do not feel that it is the purpose of the DTD to re-specify the data model. Rather, it should be the responsibility of the data model implementation to do this.
The specification being described in no way changes the operations that have been defined in the POSC Exchange format specification. It is still appropriate to select the instances based on a select criterion, and to have the exchange operations bring in the necessary, related instances to fully represent the selected instances. This includes the identifier instances that are assumed to be widely known (such as POSC fixed and Open reference data) at the level of identifying attributes only.
There will be a provision for the Epicentre Exchange Objects to be included in the XML Exchange file.
The POSC Exchange file objects are explicitly modelled as XML objects. The objects are the DAE_Data_Set_Header, the DAE_Data_Store_Root, the DAE_Exchange_Profile, the DAE_Export_Descriptor, and the DAE_Import_Descriptor. These are modelled consistent with the data types below. However, the Tag names will be modified as given in the section below.
The POSC Exchange File will consist of a root Tag, followed by the PEF Objects, followed by the Exchange Set:
DTD: <!ELEMENT POSC_ExchangeFile (PEFObjects, ExchangeSet)>
<!ELEMENT PEFObjects (DSHeader+, DSRoot?, ExchangeProfile?,
ExportDescriptor?, ImportDescriptor?)>
<!ELEMENT ExchangeSet (ANY)>
where the five parts of the PEFObjects Tag are given later in this file.
Entity: An instance is mapped to a Tag corresponding to the Entity that is specified in Epicentre. This is the leaf entity as defined above. The Tag is the entity name as defined in the express file. This entity name is UPPERCASE, with no spaces. Underscores "_" remain between words. All tags will contain a TagAtt id of type ID. The children of the Tag will correspond to all of the attributes of the entity – defined and inherited from supertypes.
DTD Example:
<!ELEMENT GEODETIC_DATUM (...the Attribute Tags...)>
<!ATTLIST GEODETIC_DATUM id ID #REQUIRED>
XML Example:
<GEODETIC_DATUM id="H1">
...
</GEODETIC_DATUM>
Attribute: An attribute is mapped to the attribute in lowercase as defined in the Express file. For example, description is defined as an attribute of e_and_p_data. The Tag will be ‘description’, and will be used by all subtypes of e_and_p_data. The child of the attribute will be its data type. There will be no TagAtts for an attribute. Note that only regular attributes will be considered. No attempt will be made to exchange inverse attributes, which, in general, represent one or more instances that reference the instance being exchanged. If this feature is needed, PEF XML can be extended.
DTD Example:
<!ELEMENT description (string)>
XML Example:
<description>
<string>Here is the value of the description</string>
</description>
General Note:
An attribute has a value in an associated named data type (ndt) specification. The process for mapping this into XML will be to have the attribute Tag defined as above, followed by a tag representing the data type. The named data type (ndt) specification will not be considered. Only the base data types will be mapped. In the DAE specification, these are referred to as Express Data Types and Epicentre Data Types.
Instance: There will be two choices for mapping an instance into XML. The first choice will be to have an instance reference. The instance reference will be an empty tag with an IDREF TagAtt that will reference an XMLInst that is contained in the Exchange Set. Since it may not always be the case that the XMLInst is contained in the exchange set, the alternate possibility is to use a key structure. Both will be shown below.
It is intended that the second alternative not be necessary. It is included, however, in case it is necessary.
An attribute which is a relationship will have a Tag that gives the choice of an instance or an instance-ref tag.
DTD: <!ELEMENT someAttributeTag (instance | instance-ref)>
<!ELEMENT instance (key+)>
<!ATTLIST instance instanceType CDATA #REQUIRED>
<!ELEMENT instance-ref EMPTY>
<!ATTLIST instance-ref refTo IDREF #REQUIRED>
<!ELEMENT key (real | integer | boolean | string | binary |
quantity | anyquantity | timestamp | location | angle |
instance | instance-ref )>
<!ELEMENT key name CDATA #REQUIRED>
where instance@instanceType is an Express entity name, and key@name is an Express attribute name.
The key structure is set up so that the select command can be written as follows:
select instanceType from instanceType where name = ‘(value of the key Tag)’ AND ...(repeat for each subsequent key).
The values of instance@instanceType and key@name should be case insensitive. However, it is generally assumed that the case will be appropriate for an SQL statement.
Note that an aggregate can have multiple instances of the instance and/or instance-ref subTags. Note also that a particular instance can have multiple keys (to select a particular instance) and an instance can be nested within another instance.
Following are examples of both options. Further examples are in Appendix B.
XML Example:
<ellipsoid>
<instance-ref refTo="Ell1"/>
</ellipsoid>
XML Example:
<ellipsoid>
<instance instanceType="ellipsoid">
<key name="identifier">
<string>GRS 1980</string>
</key>
</instance>
</ellipsoid>
The instance and instance-ref tags are general. However, there are special "references" that do no allow this choice. These are embedded in data type tags. These special references are for units of measure, currency units, and property kinds and sets (in frame data types). For these situations, it is mandatory that an instance be given somewhere in the file. They may be given at the identifier level only, or more fully specified if desired. Then they can be referenced in later uses.
Units of Measure. Special Note:
For units of measure, we identify the Tag, REF_UNIT_OF_MEASURE, which is the supertype of these units. Note that the acronym is used as the key for accessing these units. Note also, that this example uses the same value for the acronym value as for its id value, although this is not required. Also note that various XML interpreters may not allow some characters (such as spaces and slashes (/)) in the ID and IDREF values.
Example:
<REF_UNIT_OF_MEASURE id="m">
<acronym><string>m</string></acronym>
</REF_UNIT_OF_MEASURE>
<REF_UNIT_OF_MEASURE id="ftUS">
<acronym><string>ftUS</string></acronym>
</REF_UNIT_OF_MEASURE>
...
<quantity uom="m">8726.3</quantity>
...
<quantity uom="ftUS">9.445</quantity>
...
If it is desired to more fully specify a unit of measure, the full instance can be given, using the appropriate tag for the subtype being defined. For example, you could give a definition the unit, vara, to be .813 metres:
<REF_CUSTOMARY_UNIT_OF_MEASURE id="vara">
<acronym><string>vara</string></acronym>
</REF_CUSTOMARY_UNIT_OF_MEASURE>
<REF_UOM_SI_CONVERSION id="dummy1">
<first_unit><instance-ref refTo="vara"/></first_unit>
<second_unit><instance-ref refTo="m"/></second_unit>
<factor_b><real>.813</real></factor_b>
<factor_c><real>1.0</real></factor_c>
</REF_UOM_SI_CONVERSION>
DTD: <!ELEMENT integer (#PCDATA)>
XML Example:
<reciever_point_count>
<integer>64</integer>
</reciever_point_count>
DTD: <!ELEMENT real (#PCDATA)>
XML Example:
<spore_color_index>
<real>1.5</real>
</spore_color_index>
DTD: <!ELEMENT string (#PCDATA)>
XML Example:
<identifier>
<string>Airy 1840</string>
</identifier>
Boolean: A boolean is a restricted set of values: true or false. It is modelled as PCDATA to be consistent with other simeple data types.
DTD: <!ELEMENT boolean (#PCDATA)>
XML Example:
<preferred_flag>
<boolean>true</boolean>
</preferred_flag>
Logical: A logical is a restricted set of values: true, false, or unknown. It is modelled as PCDATA to be consistent with other simeple data types.
DTD: <!ELEMENT logical (#PCDATA)>
XML Example:
<equilibrium>
<logical>unknown</logical>
</equilibrium>
DTD: <!ELEMENT binary (#PCDATA)>
XML Example:
<digital_file>
<binary>%100100111</binary>
</digital_file>
Enumeration: The enumeration has no special format other than its underlying data type. In Epicentre, all enumerations are of type string.
Aggregates: Aggregates have no special format. Where an Attribute is an aggregate, its DTD Element will allow multiple cases of the value. Where order is important, as in a list, the order shall be as given in the XML file.
Complex: A complex is a real part and an imaginary part. Both are real numbers. Note: complex is not used in Epicentre.
DTD: <!ELEMENT complex (realPart, imaginaryPart)>
<!ELEMENT realPart (#PCDATA)>
<!ELEMENT imaginaryPart (#PCDATA)>
XML Example:
<data_value>
<complex>
<realPart>873.2251</realPart>
<imaginaryPart>-1299.389</imaginaryPart>
</complex>
</data_value>
Rational: A rational is a numerator and denominator, both of type integer.
DTD: <!ELEMENT rational (numerator, denominator)>
<!ELEMENT numerator (#PCDATA)>
<!ELEMENT denominator (#PCDATA)>
XML Example:
<bin_station_ratio>
<rational>
<numerator>1</numerator>
<denominator>2</denominator>
</rational>
</bin_station_ratio>
Ratio: A ratio is a numerator and denominator, one or both of which are of type real.
DTD: <!ELEMENT ratio (numerator, denominator)>
<!ELEMENT numerator (#PCDATA)>
<!ELEMENT denominator (#PCDATA)>
XML Example:
<crush_damage_ratio>
<ratio>
<numerator>87.2</numerator>
<denominator>895</denominator>
</ratio>
</crush_damage_ratio>
Money: Money consists of an amount and a currency acronym. The currency acronym is a reference to a currency definition also included in the file. The money may also consist of a subunit of type money.
DTD: <!ELEMENT money (moneyAmount, money?)>
<!ELEMENT moneyAmount (#PCDATA)>
<!ATTLIST moneyAmount currency IDREF #REQUIRED>
XML Example:
<cost>
<money>
<moneyAmount currency="USD">3779</moneyAmount>
<money>
<moneyAmount currency="USDc">27</moneyAmount>
</money>
</money>
</cost>
Quantity: A quantity is a value and a unit of measure. The unit of measure is an IDREF to an XMLInst defined in the file.
DTD: <!ELEMENT quantity (#PCDATA)>
<!ATTLIST quantity uom IDREF #REQUIRED>
XML Example:
<data_value>
<quantity uom="kg">8799</quantity>
</data_value
Anyquantity: A quantity, that also has a reference to a ref_quantity_type. The reference to the quantity type must use a previously defined instance tag.
DTD: <!ELEMENT anyquantity (quantity, quantityType)>
<!ELEMENT quantityType (instance | instance-ref)>
XML Example:
<x_max>
<anyquantity>
<quantity uom="km">800</quantity>
<quantityType>
<instance>
<instance-ref refTo="KK3"/>
</instance>
</quantityType>
</anyquantity>
</x_max>
Location: A location is a reference to a previously defined coordinate system, an optional reference to a previously defined vertex, and a list of quantity values. The list order is determined by the order in which they are listed in the XML file. The dimensionality of the location is determined by the dimensionality of the coordinate system.
DTD: <!ELEMENT location (coordinateSystem-ref, vertex-ref?,
coordinates)>
<!ELEMENT coordinates (quantity+)>
<!ELEMENT coordinateSystem-ref EMPTY>
<!ATTLIST coordinateSystem-ref refTo IDREF #REQUIRED>
<!ELEMENT vertex-ref EMPTY>
<!ATTLIST vertex-ref refTo IDREF #REQUIRED>
XML Example:
<data_value>
<location>
<coordinateSystem-ref refTo="NAD27">
<coordinates>
<quantity uom="dega">30.275993</quantity>
<quantity uom="dega">-98.931124</quantity>
</coordinates>
</location>
</data_value>
Date: A date is a year, a month, and a day. The year is four digits, the month is one or two digits, and the day is one or two digits. These are given in separate tags. All are made optional, in case it is appropriate to only give a portion of the date. At this point, implementations of databases require all three parts.
DTD: <!ELEMENT date (year?, (month | (month, day))?>
<!ELEMENT year (#PCDATA)>
<!ELEMENT month (#PCDATA)>
<!ELEMENT day (#PCDATA)>
XML Example:
<effective_date>
<date>
<year>1992</year>
<month>04</month>
<day>12</day>
</date>
</effective_date>
Time: A time consists of an hour, a minute, a second, and a time zone indication. The hour is one or two digits from 00 to 23, the minute is an integer from 0 to 59, and the second is a real number from 0 to 61. The time zone indication is the UCT offset, given as a signed real value. The time zone indication may also be a string value defining the time zone, such a Greenwich or Central Standard. Note: the time data type is not used alone in Epicentre. It is, however, used as part of the timestamp.
DTD: <!ELEMENT time (hour, (minute | (minute, second))?,
(uctOffset | timeZone)? )>
<!ELEMENT hour (#PCDATA)>
<!ELEMENT minute (#PCDATA)>
<!ELEMENT second (#PCDATA)>
<!ELEMENT uctOffset (#PCDATA)>
<!ELEMENT timeZone (#PCDATA)>
XML Example:
<data_value>
<time>
<hour>14</hour>
<minute>25</hour>
<timeZone>Central Daylight</timeZone>
</time>
</data_value>
Timestamp: A timestamp is a combination of a date and (optionally) a time.
DTD: <!ELEMENT timestamp (date, time?)>
XML Example:
<expiry_date>
<timestamp>
<date>
<year>2002</year>
<month>06</month>
<day>30</day>
</date>
<time>
<hour>12</hour>
<uctOffset>-5</uctOffset>
</time>
</timestamp>
</expiry_date>
Yearmonthinterval: An interval of time which consists of a years and months value. Note: This data type is not used in Epicentre. It is modelled here only for completeness.
DTD: <!ELEMENT yearmonthinterval (yearInterval, monthInterval)>
<!ELEMENT yearInterval (#PCDATA)>
<!ELEMENT monthInterval (#PCDATA)>
Daytimeinterval: An interval of time which consists of a number of days, hours, minutes, and seconds. All of these are optional so that various types of interval expressions can be accomodated.
DTD: <!ELEMENT daytimeinterval (dayInterval, hourInterval,
minuteInterval, secondInterval)>
<!ELEMENT dayInterval (#PCDATA)>
<!ELEMENT hourInterval (#PCDATA)>
<!ELEMENT minuteInterval (#PCDATA)>
<!ELEMENT secondInterval (#PCDATA)>
XML Example:
<activity_duration>
<daytimeinterval>
<dayInterval>7</dayInterval>
</daytimeinterval>
</activity_duration>
Angle: An angle may be passed in either the DMS format or the decimal degrees format. When passed in the DMS format, the degrees, minutes, and seconds will be in separate tags. The direction tagAtt will be one of N, E, S, W, +, -. By convention, the + corresponds to N or E, and the – corresponds to S or W.
Note that the minutes and seconds tags are optional. In general, they should be included.
DTD: <!ELEMENT angle (quantity | dms)>
<!ELEMENT dms (angleDegrees,
(angleMinutes, (angleMinutes, angleSeconds)?)?)>
<!ELEMENT angleDegrees (#PCDATA)>
<!ELEMENT angleMinutes (#PCDATA)>
<!ELEMENT angleSeconds (#PCDATA)>
<!ATTLIST angleDegrees
direction (N | E | S | W | + | -) #REQUIRED>
XML Example:
<greenwich_longitude>
<angle>
<dms>
<angleDegrees>23</angleDegrees>
<angleMinutes>42</angleMinutes>
<angleSeconds>58.815</angleSeconds>
<direction value="E">
</dms>
</angle>
</greenwich_longitude>
Point: A point is a location and a set of properties at that location.
DTD: <!ELEMENT point (location, (propertyReal | propertyString)+)>
<!ELEMENT propertyReal
(propertyKind-ref, coordAxis-ref?, quantity)>
<!ELEMENT propertyString (propertyKind-ref, string)>
<!ELEMENT propertyKind-ref EMPTY>
<!ATTLIST propertyKind-ref refTo IDREF #REQUIRED>
<!ELEMENT coordAxis-ref EMPTY>
<!ATTLIST coordAxis-ref refTo IDREF #REQUIRED>
Line: A line is a discrete set of points given within a coordinate system. The coordinate values of a line require a relationship to a coordinate system. The TagAtt, count, is the number of points that will be given in each leaf frame. The TagAtt storageOrder gives the order of the storage axes on the grid. Axis 1 is the slowest change axis, and the highest number represents the most rapidly changing axis. Since this is a line data type, there is one descriptor, and one leaf frame for each axis of the coordinate system.
The listOfValues is a list of "count" data values, separated by spaces or line returns.
DTD: <!ELEMENT line (geometryFrame, leafFrame+)>
<!ELEMENT geometryFrame (coordinateSystem-ref, gridDescription,
vertex-ref?)>
<!ATTLIST geometryFrame detailedType (FT_LINE | FT_CLOSED_LINE
| FT_SURFACE | FT_CLOSED_SURFACE | FT_MESH | FT_VOLUME
| FT_CLOSED_VOLUME | FT_CORNER_POINT | FT_UNSTRUC_3GEOM
| FT_UNSTRUC_3GEOM_SPARSE | FT_SLINE | FT_SCLOSED_LINE
| FT_SSURFACE | FT_SCLOSED | FT_SVOLUME
| FT_SCLOSED_VOLUME | FT_SCORNER_POINT
| FT_SUNSTRUC_3GEOM | FT_ARRAY_1D | FT_ARRAY_2D
| FT_ARRAY_3D) #REQUIRED>
<!ELEMENT gridDescription (grid-ref, descriptor+)
<!ELEMENT grid-ref EMPTY>
<!ATTLIST grid-ref refTo IDREF #REQUIRED>
<!ELEMENT descriptor EMPTY>
<!ATTLIST descriptor count CDATA #REQUIRED
storageOrder (1|2|3|4|5|6|7|8|9|10) #REQUIRED
lowerBound CDATA #IMPLIED>
<!ELEMENT leafFrame ((propertyKind-ref | coordAxis-ref | propertySet-ref),
uom-ref, listOfValues)>
<!ELEMENT uom-ref EMPTY)
<!ATTLIST uom-ref refTo IDREF #REQUIRED>
<!ELEMENT listOfValues (#PCDATA)>
XML Example:
<data_value>
<line>
<geometryFrame detailedType="FT_LINE">
<coordinateSystem-ref refTo="CS18"/>
<gridDescription>
<grid-ref refTo="GR18"/>
<descriptor storageOrder="1" count="12"/>
</gridDescription>
</geometryFrame>
<leafFrame>
<coordAxis-ref refTo="AX18-1"/>
<uom-ref refTo="ftUS"/>
<listOfValues>12936.3 12953.2 12970.1 12987.0
13004.0 13020.9 13037.8 13054.7
13071.6 13088.6 13105.5 13122.4
</listOfValues>
</leafFrame>
<leafFrame>
<coordAxis-ref refTo="AX18-2"/>
<uom-ref refTo="ftUS"/>
<listOfValues>81127.4 81142.5 81157.6 81172.6
81187.7 81202.8 81217.8 81232.9
81238.0 81253.1 81268.1 812283.2
</listOfValues>
</leafFrame>
</line>
</data_value>
Surface (Grid): A surface is a discrete set of points given within a coordinate system. This tag is appropriate for the grid type of surfaces. The coordinate values of a surface require a relationship to a coordinate system. The TagAtt, count, is the number of points that will be given for each axis in each leaf frame. The TagAtt storageOrder gives the order of the storage axes on the grid. Since this is a surface data type, there are two descriptors. In the descriptors, Axis 1 is the slowest change axis, and Axis 2 represents the most rapidly changing axis. The total number of values that will be in each leaf frame is the product of the two count values of the descriptors.
There is one leaf frame for each axis of the coordinate system. The listOfValues is a list of "count" data values, separated by spaces or line returns.
DTD: <!ELEMENT surface (gridSurface | contourSurface)>
<!ELEMENT gridSurface (geometryFrame, leafFrame+)>
Surface (contour): A surface may be represented by a set of contour lines. Each of these lines is a line geometry type, that has a single contour value.
DTD: <!ELEMENT contourSurface (propertyKind-ref, uom-ref,
isoLine+)>
<!ELEMENT isoLine (isoValue, line)>
<!ELEMENT isoValue (real)>
Volume: A volume is a discrete set of points given within a coordinate system. The coordinate values of a volume require a relationship to a coordinate system. The TagAtt, count, is the number of points that will be given for each axis in each leaf frame. The TagAtt storageOrder gives the order of the storage axes on the grid. Since this is a volume data type, there are three descriptors. In the descriptors, Axis 1 is the slowest change axis, and Axis 3 represents the most rapidly changing axis.. The total number of values that will be in each leaf frame is the product of the three count values of the descriptors.
There is one leaf frame for each axis of the coordinate system. The listOfValues is a list of "count" data values, separated by spaces or line returns.
DTD: <!ELEMENT volume (geometryFrame, leafFrame+)>
Element: An element is a property value assigned to each point of a grid. Within a given instance of an element, the property values must all be the same property and the same unit of measure. Note: In v3.0 there is a relationship to property_kind. In previous versions of Epicentre, the relationship is to ref_property_kind. The Tag propertyKind is intended to cover both of these cases.
DTD: <!ELEMENT element (propertyFrame, leafFrame+)>
<!ELEMENT propertyFrame (gridDescription, grid2-ref?)>
<!ATTLIST propertyFrame detailedType (EGRID_1DNODE
| EGRID_1DEDGE | ETRIMESHNODE | ETRIMESHEDGE | ETRMESHFACE
| EGRID_2DNODE | EGRID_2DEDGE | EGRID_2DFACE | EGRID_3DNODE
| EGRID_3DEDGE | EGRID_3DFACE | EGRID_3DCELL | EGRID_CPCELL
| EGRID_CPEDGE | EGRID_CPFACE | EGRID_CPNODE | EUSGEOM_CELL
| EUSGEOM_EDGE | EUSGEOM_FACE | EUSGEON_NODE | SGRID_1DNODE
| SGRID_1DEDGE | SGRID_1DEDGEPAIR | STRIMESHNODE
| STRIMESHEDGE | STRIMESHFACE | STRIMESHEDGEPAIR
| STRIMESHFACEPAIR | SGRID_2DNODE | SGRID_2DEDGE
| SGRID_2DFACE | SGRID_2DEDGEPAIR | SGRID_2DFACEPAIR
| SGRID_3DNODE | SGRID_3DEDGE | SGRID_3DFACE | SGRID_3DCELL
| SGRID_3DEDGEPAIR | SGRID_3DFACEPAIR | SGRID_3DCELLPAIR
| SGRID_CPCELL | SGRID_CPEDGE | SGRID_CPFACE | SGRID_CPNODE
| SGRID_CPCELLPAIR | SGRID_CPEDGEPAIR | SGRID_CPFACEPAIR
| SGRID_CPNODEPAIR | SUSGEOM_CELL | SUSGEOM_EDGE
| SUSGEOM_FACE | SUSGEOM_NODE | SUSGEOM_CALLPAIR
| SUSGEOM_EDGEPAIR | SUSGEOM_FACEPAIR | SUSGEOM|NODEPAIR)
#REQUIRED>
<!ELEMENT grid2-ref EMPTY>
<!ATTLIST grid2-ref refTo IDREF #REQUIRED>
A sample data type is a repeat of samples, which consists of a sample index, and a set of property values (measured, recorded, etc.). For example, a sample of crude oil may have a set of (pressure, temperature, volume) values. Note that since there is no specified or implied ordering to the sample values, there is no grid associated with the data type.
DTD: <!ELEMENT sample (descriptor, leafFrame+)>
<!ELEMENT propertySet-ref EMPTY>
<!ATTLIST propertySet-ref refTo IDREF #REQUIRED>
An unstructured 3d topology is a set of relationships among cells, faces, edges, and nodes. It locates the cells, faces, and edges by relating them to nodes. A node is the only object in this data type that might have a location. Since this is a topological object, the locations of the nodes is made optional. However, it is also possible to give locations for one or more of the nodes.
The four topological objects are identified with an integer value. The integer is assumed to be unique within the object and within a particular instance. Thus, it is possible to label the nodes as 1, 2, 3, ... and also to label the edges as 1, 2, 3, ..., etc. In addition, it is possible to instantiate a second unstructure 3d topology, and to have the same basic numbers. These are not to be modelled as ID and IDREF datatypes.
The nodes stand alone. The edges are made up of a list of two or more nodes. An edge may also have a center node that is used to locate it. A face is made up of two or more edges. A face may also have a center node. In addition, a face may give a set of adjacent faces. Finally, a cell is composed of two or more faces - also with the possibility of a center node.
An unstructured 3d topology was developed as a programmer's construct, so that the semantics of the various sets of information is known to a programmer.
DTD: <!ELEMENT unstructured_3d_topology (3dnode+, (3dedge+, (3dface+, 3dcell*)?)?)>
<!ELEMENT 3dnode (location?)>
<!ATTLIST 3dnode id CDATA #REQUIRED>
<!ELEMENT 3dedge (hasNode+, centerNode?)>
<!ATTLIST 3dedge id CDATA #REQUIRED>
<!ELEMENT hasNode EMPTY>
<!ATTLIST hasNode refTo CDATA #REQUIRED>
<!ELEMENT centerNode EMPTY>
<!ATTLIST centerNode refTo CDATA #REQUIRED>
<!ELEMENT 3dface (hasEdge+, (centerNode | adjacentFace)*)>
<!ATTLIST 3dface id CDATA #REQUIRED>
<!ELEMENT hasEdge EMPTY>
<!ATTLIST hasEdge refTo CDATA #REQUIRED>
<!ELEMENT adjacentFace EMPTY>
<!ATTLIST adjacentFace refTo CDATA #REQUIRED>
<!ELEMENT 3dcell (hasFace+, centerNode?)>
<!ATTLIST 3dcell id CDATA #REQUIRED>
<!ELEMENT hasFace EMPTY>
<!ATTLIST hasFace refTo CDATA #REQUIRED>
XML Example:
<unstructured_3d_topology>
<3dnode id="1">
<location>
<coordinateSystem-ref refTo="somelocalsystem">
<coordinates>
<quantity uom="ft">0.</quantity>
<quantity uom="ft">0.</quantity>
<quantity uom="ft">0.</quantity>
</coordinates>
</location>
</3dnode>
<3dnode id="2">
<location>
<coordinateSystem-ref refTo="somelocalsystem">
<coordinates>
<quantity uom="ft">1.</quantity>
<quantity uom="ft">0.</quantity>
<quantity uom="ft">0.</quantity>
</coordinates>
</location>
</3dnode>
<3dnode id="3">
<location>
<coordinateSystem-ref refTo="somelocalsystem">
<coordinates>
<quantity uom="ft">0.</quantity>
<quantity uom="ft">1.</quantity>
<quantity uom="ft">0.</quantity>
</coordinates>
</location>
</3dnode>
<3dnode id="4">
<location>
<coordinateSystem-ref refTo="somelocalsystem">
<coordinates>
<quantity uom="ft">0.</quantity>
<quantity uom="ft">0.</quantity>
<quantity uom="ft">1.</quantity>
</coordinates>
</location>
</3dnode>
<3dedge id="1">
<hasNode refTo="1">
<hasNode refTo="2">
</3dedge>
<3dedge id="2">
<hasNode refTo="1">
<hasNode refTo="3">
</3dedge>
<3dedge id="3">
<hasNode refTo="1">
<hasNode refTo="4">
</3dedge>
<3dedge id="4">
<hasNode refTo="2">
<hasNode refTo="3">
</3dedge>
<3dedge id="5">
<hasNode refTo="2">
<hasNode refTo="4">
</3dedge>
<3dedge id="6">
<hasNode refTo="3">
<hasNode refTo="4">
</3dedge>
<3dface id="1">
<hasEdge refTo="1">
<hasEdge refTo="2">
<hasEdge refTo="4">
</3dface>
<3dface id="2">
<hasEdge refTo="1">
<hasEdge refTo="3">
<hasEdge refTo="5">
</3dface>
<3dface id="3">
<hasEdge refTo="2">
<hasEdge refTo="3">
<hasEdge refTo="6">
</3dface>
<3dface id="4">
<hasEdge refTo="4">
<hasEdge refTo="5">
<hasEdge refTo="6">
</3dface>
<3dcell id="1">
<hasFace refTo="1">
<hasFace refTo="2">
<hasFace refTo="3">
<hasFace refTo="4">
</3dcell>
</unstructured_3d_topology>
One of the problems of DTD’s is that they overspecify a data model, in the sense that a DTD specifies an ordering of the subtags. In general, order is unimportant in a list of attributes for an entity.
An additional difficulty is that the exchange set is often incomplete, in that it does not match the specifications of the data model. In particular, the identifier set of the exchange set needs only to contain the attributes that serve to identify the instance. All other mandatory and optional attributes are not included. Thus, it becomes difficult to automatically develop the DTD for such an exchange set.
Thus, a skeletal DTD will be developed. The DTD will be a compendium of the data types, as given above, coupled with all the attributes of Epicentre, and the DTD for the Exchange Objects. There will be no attempt to compile the attributes into subtags of the entity Tag. This will allow the sender of the XML file to create it without having to worry about the order as specified in a DTD.
These objects are modelled separately, rather than using the string data type as defined above.
A header that contains information about the exchange set and the data model. This differs from the DAE Specification in that the data model (Attribute: data_model) and other attributes are not included in the data set.
DTD: <!ELEMENT DSHeader (DAEauthor*, DAEauthorizations,
DAEdata_model_id?, DAEdata_model_version?, DAEdescription?,
DAEname, DAEorganization*, DAEquality_report*,
DAEtime_stamp?)>
<!ATTLIST DSHeader id ID #REQUIRED>
<!ELEMENT DAEauthor (#PCDATA)>
<!ELEMENT DAEauthorizations (#PCDATA)>
<!ELEMENT DAEdata_model_id (#PCDATA)>
<!ELEMENT DAEdata_model_version (#PCDATA)>
<!ELEMENT DAEdescription (#PCDATA)>
<!ELEMENT DAEname (#PCDATA)>
<!ELEMENT DAEorganization (#PCDATA)>
<!ELEMENT DAEquality_report (#PCDATA)>
<!ELEMENT DAEtime_stamp (timestamp)>
There may be more than one data set header (DSHeader) in the exchange set. This identifies which one is the root header. This Tag is optional.
DTD: <!ELEMENT DSRoot EMPTY>
<!ATTLIST DSRoot refTo IDREF #REQUIRED>
The exchange profile is the formal specification of the data being sent. The specification gives an indication of which instances are to be brought in. It does this by giving the mandatory attributes, and the definition of the public instances. The public instances are those Epicentre instances that are given with the identifying information only. In the XML exchange set, these instances should be included with identifying instances only so that they may be referenced by other instances. They include, for example, reference data and units of measure.
DTD: <!ELEMENT ExchangeProfile (DAEname, DAEversion?, DAEnamespace,
DAEidentifierCriteria?, DAEminimumContentCriteria?,
DAEscope, (DAEmodelID, DAEmodelVersion)?,
DAEdescription?)>
<!ELEMENT DAEversion (#PCDATA)>
<!ELEMENT DAEnamespace (#PCDATA)>
<!ELEMENT DAEidentifierCriteria (#PCDATA)>
<!ELEMENT DAEminimumContentCriteria (#PCDATA)>
<!ELEMENT DAEscope (#PCDATA)>
<!ELEMENT DAEmodelID (#PCDATA)>
<!ELEMENT DAEmodelVersion (#PCDATA)>
The export descriptor is the definition of how the data is obtained from a data store. It may be from a public profile that has been developed and stored, or from a private description. This description is generally a SQL statement, and is stored in the initial_criteria attribute.
DTD: <!ELEMENT ExportDescriptor (DAEname, DAEinitialCriteria,
DAEdescription?, DAEheader?, DAEprofile?)>
<!ELEMENT DAEinitialCriteria (#PCDATA)>
<!ELEMENT DAEheader EMPTY>
<!ATTLIST DAEheader refTo IDREF #REQUIRED>
<!ELEMENT DAEprofile EMPTY>
<!ATTLIST DAEprofile refTo IDREF #REQUIRED>
The import descriptor is an optional object that tells the receiving set how to merge the data into its database.
DTD: <!ELEMENT ImportDescriptor (DAEname, DAEdescription?,
DAEprofile?, DAEdeleteCriteria?, DAEfillCriteria?,
DAErefreshCriteria?)>
<!ELEMENT DAEdeleteCriteria (#PCDATA)>
<!ELEMENT DAEfillCriteria (#PCDATA)>
<!ELEMENT DAErefreshCriteria (#PCDATA)>
Following are examples of a single instance of a geodetic datum using both methods:
STEP 28 Mapping:
<e_and_p_data id="A11">
<e_and_p_data.description>
<ndt_comment>
<string>Fundamental point: ... (west of Greenwich)</string>
</ndt_comment>
</e_and_p_data.description>
<e_and_p_data.source>
<ndt_identifier>
<string>POSC</string>
</ndt_identifier>
</e_and_p_data.source>
<e_and_p_data-subtypes>
<object_of_interest id="B11">
<object_of_interest-subtypes>
<technical_object id="C11">
<technical_object-subtypes>
<technical_reference id="D11">
<technical_reference.identifier>
<ndt_identifier>
<string>NAD27</string>
</ndt_identifier>
</technical_reference.identifier>
<technical_reference.status>
<ndt_instance_status value="current"/>
</technical_reference.status>
<technical_reference.version>
<instance instanceType="ref_version">
<key name="identifier">
<string>epicentre 2.1</string>
</key>
</instance>
</technical_reference.version>
<technical_reference-subtypes>
<aliasable_technical_reference id="E11">
<aliasable_technical_reference.naming_system>
<instance instanceType="naming_system">
<key name="identifier">
<string>EPSG preferred name</string>
</key>
</instance>
</aliasable_technical_reference.naming_system>
<aliasable_technical_reference-subtypes>
<datum id="F11">
<datum-subtypes>
<geodetic_datum id="G11">
<geodetic_datum.ellipsoid>
<instance instanceType="ellipsoid">
<key name="identifier">
<string>Clarke 1866</string>
</key>
</instance>
</geodetic_datum.ellipsoid>
<geodetic_datum.prime_meridian>
<instance instanceType="prime_meridian">
<key name="identifier">
<string>Greenwich</string>
</key>
</instance>
</geodetic_datum.prime_meridian>
</geodetic_datum>
</datum-subtypes>
</datum>
</aliasable_technical_reference-subtypes>
</aliasable_technical_reference>
</technical_reference-subtypes>
</technical_reference>
</technical_object-subtypes>
</technical_object>
</object_of_interest-subtypes>
</object_of_interest>
</e_and_p_data-subtypes>
</e_and_p_data>
Here is the Example of the same data put into the proposed PEF XML format:
PEF XML Mapping:
<GEODETIC_DATUM id="A11">
<description>
<string>Fundamental point: ... (west of Greenwich)</string>
</description>
<source>
<string>POSC</string>
</source>
<identifier>
<string>NAD27</identifier>
</identifier>
<version>
<instance instanceType="ref_version">
<key name="identifier">
<string>epicentre 2.1</string>
</key>
</instance>
</version>
<naming_system>
<instance instanceType="naming_system">
<key name="identifier">
<string>EPSG preferred name</string>
</key>
</instance>
</naming_system>
<ellipsoid>
<instance instanceType="ellipsoid">
<key name="identifier">
<string>Clarke 1866</string>
</key>
</instance>
</ellipsoid>
<prime_meridian>
<instance instanceType="prime_meridian">
<key name="identifier">
<string>Greenwich</string>
</key>
</instance>
</prime_meridian
</GEODETIC_DATUM>
Differences:
Multiple and Nested instance: A wellbore_pick has a relationship to a wellbore, which, in turn, is identified by the well it is within. Here are two methods for setting these up. The first uses the instance-ref tag, and the second uses the instance (and key) tags.
Using instance-ref:
<!--Need only identifier information for Well and Wellbore-->
<WELL id="A1">
<identifier><string>5002920408</string></identifier>
</WELL>
<WELLBORE id="B1">
<identifier><string>00</string></identifier>
<well><instance-ref refTo="A1"/></well>
</WELLBORE>
<!--Here is where we find full information-->
<WELLBORE_PICK id="C1">
<identifier>
<string>Top of the Dargenic</string>
</identifier>
<wellbore><instance-ref refTo="B1"></wellbore>
...(other attributes)...
</WELLBORE_PICK>
Using instance and key:
<WELLBORE_PICK id="C1">
<identifier>
<string>Top of the Dargenic</string>
</identifier>
<wellbore>
<instance instanceType="wellbore">
<key name="identifier"><string>00</string></key>
<key name="well">
<instance instanceType="well">
<key name="identifier"><string>5002920408
</string></key>
</instance>
</key>
</instance>
</wellbore>
...(other attributes)...
</WELLBORE_PICK>