The file, PEFxml.zip, contains the XML Schemas, and a sample XML file. Download the PEFxml.zip file.
Status of POSC Exchange File, XML Format, Recommendation:
The initial presentation of the POSC Exchange File, XML Format, was introduced in November 2000. It has been changed based on comments received, and based on related work in closely allied areas. The following document is the recommendation of POSC for using XML to exchange data from the epicentre data model.
While there is no inherent limit on the applicability of the following exchange file, there is a definite practical limitation. Large files do not transfer well when invoking the Document Object Model. Thus, it is recommended that the exchange sets be kept to fewer than 3 Mbytes. Further use of this exchange file format may change this recommendation.
The mapping from the Epicentre data model into an XML formatted file is accomplished at four levels:
Mapping of Epicentre datatypes into XML elements.
Mapping of Epicentre attributes into XML elements.
Mapping of Epicentre entities into XML elements.
Combining the Exchange Set with other information to form the POSC Exchange File.
It is expected that some parts of the Recommendation will change with experience. The following are considered to be normative, and are considered to be stable portions of this recommendations:
Mapping of entities
Mapping of attributes
Mapping of instances
Referencing of units.
Mapping of the following datatypes:
integer, real, string, boolean, logical, binary, enumeration, aggregates, complex, rational, ratio, money, quantity, location, date, time, timestamp, angle.
The following are open questions. These are not normative, and are subject to change:
The PEF Header (PEF Operations and PEF Objects sections) are not normative.
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. At this point, the data exchange objects are mapped directly from the Data Exchange Specification.
Please send comments to bobbitt@posc.org.
In addition to this specification, there will is a usage document that explains how to write PEF XML files. The document is not normative.
The document previous to this was a discussion paper, with a call for comments. The present document contains many parts of the original document. However, for reference, the previous document, Epicentre XML Exchange Format is referenced in full.
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. This is done by the describing a process for converting from Epicentre entities, attributes, and data types to XML elements. The process also has rules for generating an XML schema from the Epicentre data model.
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.
There are three main purposes for this recommendation:
In developing the method, the main principle behind the design has been to make the method as simple as possible for reading and writing applications. The set of rules for developing and reading an XML file are simple. In addition, the schema was developed so that extensions can be readily constructed.
Developing the XML Schema is not as simple. Most of the complications in the following paper are in understanding the Schema and how it was developed. The user of PEF XML does not need to consider these complications - he only needs to consider how to develop the XML file itself.
In addition, the user of PEF XML needs to know how to extend the model to add additional entities and attributes. The structure of the schema allows this to be done very simply. Furthermore, it can be done from a remote location without having to alter the main PEF XML Schema.
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. In addition, by invoking the Epicentre data model, the recommendation assumes that the data in the XML file is consistent with the restrictions and rules on the data. It is not the purpose of the XML Schema to test for correctness of the data -- it is assumed that the data base implementation will have done this.
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:
All schema tags will be prefixed with the xsd namespace in the XML Schema.
All tags defined by POSC will be prefixed with the pef namespace in the XML Schema.
The schema developed will have elementFormDefault="qualified".
The attributes of the developed schema will be unqualified.
The illustrated sample XML will have the pef namespace as the default, with no namespace prefix.
An Epicentre entity is mapped into XML using the following rules:
The following methodology will be used for the entities in XML Schema:
<xsd:complexType name="entityType" >
<xsd:attribute name="ID" type="xsd:ID" use="required"/>
</xsd:complexType>
<element name="ENTITY" type="pef:entityType" abstract="true">
<xsd:unique name="dummy1">
<xsd:selector xpath="."/>
<xsd:field xpath="@ID"/>
</xsd:unique>
<xsd:key name="entityID">
<xsd:selector xpath="."/>
<xsd:field xpath="@ID"/>
</xsd:key>
<xsd:keyref name="instanceDummy" refer="pef:entityID">
<xsd:selector xpath=".//instance-ref"/>
<xsd:field xpath="@refTo"/>
</xsd:keyref>
</xsd:element>
All Epicentre entities will be a part of the ENTITY substitution group as illustrated below.
The schema will create an element for each leaf entity. The element will be an extension of the entityType, and will be in the substitution group, ENTITY. The content of the element will be a choice of the (forward) Epicentre attributes (no inverse attributes).
<xsd:element name="WELL_COMPLETION" substitutionGroup="ENTITY" type="WELL_COMPLETIONtype"/>
<xsd:complexType name="WELL_COMPLETIONtype">
<xsd:complexContent>
<xsd:extension base="pef:entityType">
<xsd:choice maxOccurs="unbounded">
<xsd:element name="identifier" type="pef:stringElement"/>
...all of its forward attributes...
</xsd:choice>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<WELL_COMPLETION id="wc1">
...various subelements...
</WELL_COMPLETION>
An Epicentre attribute is mapped into XML using the following rules:
<WELL_COMPLETION id="wc1">
<identifier>
<string>01A</string>
</identifier>
...other attributes of WELL_COMPLETION...
</WELL_COMPLETION>
Many of the Epicentre attributes are references to instances within an Epicentre database. The XML file may or may not physically contain that instance. Because of this possibility, every attribute that is a reference will have two choices: instance and instance-ref.
An instance-ref tag, refTo, will be a reference to an id TagAtt of a tag in the ENTITY group. In DTD terminology, the id TagAtt is of type ID, and the TagAtt, refTo, is of type IDREF. Since XML Schema is deprecating these concepts, the TagAtt, refTo, will be of type xsd:string, and the ID, IDREF construction will be implemented using the key, keyref construction.
If the XML instance is not present in the exchange file, the instance Element is used. The instance Element allows the description of the referenced instance by giving enough information so that a database user can build a select statement to select the instance from an Epicentre data base. This allows the exchange file to exchange information without having to send all the referenced instances.
In Epicentre, a well_completion has an attribute, well, which is a reference to an instance of a well. If the instance of well is present, instance-ref element may be used:
<WELL id="well1">
...some subtags...
</WELL>
...more instances...
<WELL_COMPLETION id="wcA">
<identifier>
<string>01A</string>
</identifier>
<well>
<instance-ref refTo="well1"/>
</well>
</WELL_COMPLETION>
...
If the instance is not present, the instance element must be used:
<WELL_COMPLETION id="wcA">
<identifier>
<string>01A</string>
</identifier>
<well>
<instance instanceType="well">
<key name="identifier">
<string>500292040601</string>
</key>
</instance>
</well>
...
</WELL_COMPLETION>
This example allows the formation of the SQL statement:
select well from well where identifier = '500292040601';
For references, we also define the reference datatypes:
<xsd:complexType name="reference"> <xsd:attribute name="refTo" use="required" type="xsd:string"/> </xsd:complexType> <xsd:complexType name="unitref"> <xsd:attribute name="refTo" use="required" type="xsd:anyURI"/> </xsd:complexType>
<xsd:element name="instance-ref" type="pef:reference">
<xsd:keyref name="instanceDummy" refer="pef:entityID">
<xsd:selector xpath="."/>
<xsd:field xpath="@refTo"/>
</xsd:keyref>
</xsd:element>
<xsd:complexType name="instanceType">
<xsd:sequence>
<xsd:element name="key" minOccurs="1" maxOccurs="unbounded">
<xsd:complexType">
<xsd:choice>
<xsd:element name="string" type="xsd:string"/>
<xsd:element name="integer" type=xsd:integer"/>
<xsd:element name="boolean" type="pef:booleanType"/>
<xsd:element name="binary" type="xsd:binary"/>
<xsd:element name="real" type="xsd:double"/>
<xsd:element name="quantity" type="pef:quantityType"/>
<xsd:element name="anyquantity" type="pef:anyquantityType"/>
<xsd:element name="complex" type="pef:complexNumberType"/>
<xsd:element name="ratio" type="pef:ratioType"/>
<xsd:element name="rational" type="pef:rationalType"/>
<xsd:element name="money" type="pef:moneyType"/>
<xsd:element name="date" type="pef:parsedDateType"/>
<xsd:element name="time" type="pef:parsedTimeType"/>
<xsd:element name="timestamp" type="pef:timestampType"/>
<xsd:element name="location" type="pef:locationType"/>
</xsd:choice>
<xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="instanceType" type="xsd:string"/>
</xsd:complexType>
XML Schema for instanceElement
<xsd:complexType name="instanceElement">
<xsd:choice>
<xsd:element name="instance" type="pef:instanceType"/>
<xsd:element ref="pef:instance-ref"/>
</xsd:choice>
</xsd:complexType>
The key element is set up so that the select command can be written as follows:
select instanceType from instanceType where (value of name attribute) = ‘(value of the key Tag)’ AND ...(repeat for each subsequent key).
At this writing, the method of handling units of measure and quantity types is still in a discussion phase. The basic paper can be found at the units area in the Patterns and Objects paper. This will lead to papers that can be downloaded.
The units of measure follows the proposal as outlined in this paper. Basically, it defines a quantity data type, which has a reference to a unit of measure. The unit of measure is defined in a (generally) separate area of the file, either by full definition or by reference to a units dictionary.
This recommendation follows that practice.
However, if the recommendation for the unit of measure should change, it is expected that this recommendation would also change. In particular, we will need:
XML Schema
<xsd:complexType name="unitref">
<xsd:attribute name="uom" use="required" type="xsd:anyURI"/>
</xsd:complexType>
Each of the Epicentre datatypes will be mapped into epicentre datatypes. The full mapping and an illustration of how it is used is demonstrated with the epicentre, real:
<xsd:complexType name="realElement">
<xsd:sequence>
<xsd:element name="real" type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
Use of the datatype is illustrated. When an Epicentre attribute is of datatype, real, it is mapped into XML as follows:
...the element is formed by an extension of pef:entityType...
<xsd:extension base="pef:entityType">
<xsd:choice maxOccurs="unbounded">
...here are the various attributes mapped into elements...
...In particular, here is one of type real...
<xsd:element name="spore_color" type="pef:realElement"/>
...And other element definitions...
</xsd:choice>
</xsd:extension>
Following is the mapping of all of the Epicentre datatypes. For each datatype, the XML Schema for the datatype will be given, along with an example of how it would look in XML. The Schema for its usage will not be given.
XML Schema
<xsd:complexType name="integerElement">
<xsd:sequence>
<xsd:element name="integer" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>
XML Example:
<reciever_point_count>
<integer>64</integer>
</reciever_point_count>
XML Schema
<xsd:complexType name="realElement">
<xsd:sequence>
<xsd:element name="real" type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
XML Example:
<spore_color_index>
<real>1.5</real>
</spore_color_index>
XML Schema
<xsd:complexType name="stringElement">
<xsd:sequence>
<xsd:element name="string" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
XML Example:
<identifier>
<string>Airy 1840</string>
</identifier>
Boolean: A boolean is a restricted set of values: true or false. It is modelled to accept upper case and title case, as well as the W3C lower case.
XML Schema
<xsd:complexType name="booleanElement">
<xsd:sequence>
<xsd:element name="boolean" type="pef:booleanType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="booleanType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="true"/>
<xsd:enumeration value="True"/>
<xsd:enumeration value="TRUE"/>
<xsd:enumeration value="false"/>
<xsd:enumeration value="False"/>
<xsd:enumeration value="FALSE">
</xsd:restriction>
</xsd:simpleType>
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 to accept upper case and title case, as well as the W3C lower case.
XML Schema
<xsd:complexType name="logicalElement">
<xsd:sequence>
<xsd:element name="logical" type="pef:logicalType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="logicalType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="true"/>
<xsd:enumeration value="True"/>
<xsd:enumeration value="TRUE"/>
<xsd:enumeration value="false"/>
<xsd:enumeration value="False"/>
<xsd:enumeration value="FALSE">
<xsd:enumeration value="unknown"/>
<xsd:enumeration value="Unknown"/>
<xsd:enumeration value="UNKNOWN">
</xsd:restriction>
</xsd:simpleType>
XML Example:
<equilibrium>
<logical>unknown</logical>
</equilibrium>
XML Schema
<xsd:complexType name="binaryElement">
<xsd:sequence>
<xsd:element name="binary" type="xsd:binary"/>
</xsd:sequence>
</xsd:complexType>
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 Schema 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. The value of the element is considered to be at the datatype Tag level. For example, an aggregate (SET) of type string would appear as follows:
<aggregate_attribute>
<string>one value</string>
<string>another value</string>
<string>yet another value</string>
</aggregate_attribute>
No schema definitions are given for the aggregates since Epicentre 3.0 does not have any aggregates among its forward attributes. For data models which do contain aggregates, the general procedure should be to alter the complexType of type xxxElement to have maxOccurs="unbounded" at the sequence or choice level.
Complex: A complex is a real part and an imaginary part. Both are real numbers. Alternatively, a complex number may be a modulus and an angle. Note: complex is not used in Epicentre.
XML Schema:
<xsd:complexType name="complexNumberElement">
<xsd:sequence>
<xsd:element name="complex" type="pef:complexNumberType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="complexNumberType">
<xsd:choice>
<xsd:sequence>
<xsd:element name="realPart" type="xsd:double"/>
<xsd:element name="imaginaryPart" type="xsd:double"/>
</xsd:sequence>
<xsd:sequence>
<xsd:element name="modulus" type="xsd:double"/>
<xsd:element name="angle" type="xsd:double"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>
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.
XML Schema:
<xsd:complexType name="rationalElement">
<xsd:sequence>
<xsd:element name="rational" type="pef:rationalType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="rationalType">
<xsd:sequence>
<xsd:element name="numerator" type="xsd:integer"/>
<xsd:element name="denominator" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>
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.
XML Schema:
<xsd:complexType name="ratioElement">
<xsd:sequence>
<xsd:element name="ratio" type="pef:ratioType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ratioType">
<xsd:sequence>
<xsd:element name="numerator" type="xsd:double"/>
<xsd:element name="denominator" type="xsd:double"/>
</xsd:sequence>
</xsd:complexType>
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 symbol. The money may also consist of a subunit of type money. Although Epicentre splits the currency and its subunits into separate instances, the PEF XML will consider them to a single, decimal-formatted amount.
The XML Schema uses a currencies data type, which is an enumeration of the ISO currency symbols, available in the V2.2 and V3.0 Epicentre database.
XML Schema:
<xsd:complexType name="moneyElement">
<xsd:sequence>
<xsd:element name="money" type="pef:moneyType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="moneyType">
<xsd:simpleContent>
<xsd:extension base="xsd:decimal">
<xsd:attribute name="currency" type="pef:currencies"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
XML Example:
<cost>
<money currency="USD">3779.27</money>
</cost>
Quantity: A quantity is a value and a unit of measure. The unit of measure is a reference to an XMLInst defined in the file. Note that the ExchangeSet level should have a keyref defined for the uom attribute of all elements of type quantityType.
XML Schema:
<xsd:complexType name="quantityElement">
<xsd:sequence>
<xsd:element name="quantity" type="pef:quantityType"/gt;
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="quantityType"/gt;
<xsd:simpleContent>
<xsd:extension base="xsd:double"/>
<xsd:attribute name="uom" type="xsd:anyURI"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
XML Example:
<data_value>
<quantity uom="#kg">8799</quantity>
</data_value>
Anyquantity: A quantity, that also has a reference to a ref_quantity_type.
XML Schema:
<xsd:complexType name="anyquantityType">
<xsd:sequence>
<xsd:element name="quantityValue" type="pef:quantityType"/>
<xsd:element name="quantityType" type="pef:instanceElement"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="anyquantityElement">
<xsd:sequence>
<xsd:element name="anyquantity" type="pef:anyquantityType"/>
</xsd:sequence>
</xsd:complexType>
XML Example:
<x_max>
<anyquantity>
<quantityValue uom="#km">800</quantityValue>
<quantityType>
<instance-ref refTo="KK3"/>
</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.
XML Schema:
<xsd:complexType name="locationElement">
<xsd:sequence>
<xsd:element name="location" type="pef:locationType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="locationType">
<xsd:sequence>
<xsd:element name="coordinateSystem" type="pef:instanceElement"/>
<xsd:element name="vertex-ref" type="pef:reference" minOccurs="0"/>
<xsd:element name="coordinates"/>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="value" type="pef:quantityType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
XML Example:
<data_value>
<location>
<coordinateSystem>
<instance-ref refTo="NAD27"/>
</coordinateSystem>
<coordinates>
<value uom="#dega">30.275993</value>
<value uom="#dega">-98.931124</value>
</coordinated>
</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.
XML Schema:
<xsd:complexType name="dateElement">
<xsd:sequence>
<xsd:element name="date" type="pef:parsedDateType"/>
</xsd:sequence>
<xsd:complexType>
<xsd:complexType name="parsedDateType">
<xsd:sequence>
<xsd:element name="year"/>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9](4)"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:sequence minOccurs="0" maxOccurs="1">
<xsd:element name="month"/>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="(0?[1-9])|(1[0-2])"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="day" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="(0?[1-9])|([1,2][0-9])|(3[0-1])"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:sequence>
</xsd:complexType>
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.
XML Schema:
<xsd:complexType name="timeElement">
<xsd:sequence>
<xsd:element name="time" type="pef:parsedTimeType"/>
</xsd:sequence>
<xsd:complexType>
<xsd:complexType name="parsedTimeType">
<xsd:sequence>
<xsd:element name="hour">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="([0?1][0-9])|2[0-3])"/>
</xsd:restriction>
</xsd:simpleType>>
</xsd:element>
<xsd:sequence minOccurs="0" maxOccurs="1">
<xsd:element name="minute">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="([0?12345][0-9])"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="second" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0.00"/>
<xsd:maxInclusive value="60.00"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
<xsd:choice>
<xsd:element name="uctOffset">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="-13.0"/>
<xsd:maxInclusive value="12.0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="timeZone" type="xsd:string"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
XML Example:
<data_value>
<time>
<hour>14</hour>
<minute>25</hour>
<timeZone>CDT</timeZone>
</time>
</data_value>
Timestamp: A timestamp is a combination of a date and (optionally) a time.
XML Schema:
<xsd:complexType name="timestampElement"/>
<xsd:sequence>
<xsd:element name="timestamp" type="pef:timestampType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="timestampType">
<xsd:sequence>
<xsd:element name="date" type="pef:parsedDateType"/>
<xsd:element name="time" type="pef:parsedTimeType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
XML Example (expiry_date at noon, CDT, of June 30, 2002):
<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.
XML Schema:
<xsd:complexType name="yearmonthintervalElement">
<xsd:sequence>
<xsd:element name="yearmonthinterval" type="yearmonthintervalType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="yearmonthintervalType">
<xsd:sequence>
<xsd:element name="yearInterval" type="xsd:positiveInteger" minOccurs="0"/>
<xsd:element name="monthInterval" type="xsd:positiveInteger"/>
</xsd:sequence>
</xsd:complexType>
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.
XML Schema:
<xsd:complexType name="daytimeintervalElement">
<xsd:sequence>
<xsd:element name="daytimeinterval" type="daytimeintervalType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="daytimeintervalType">
<xsd:sequence>
<xsd:element name="dayInterval" type="xsd:positiveInteger" minOccurs="0"/>
<xsd:element name="hourInterval" type="xsd:positiveInteger" minOccurs="0"/>
<xsd:element name="minuteInterval" type="xsd:positiveInteger" minOccurs="0"/>
<xsd:element name="secondInterval" type="xsd:decimal" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
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.
XML Schema:
<xsd:complexType name="angleElement">
<xsd:sequence>
<xsd:element name="angle" type="pef:angleType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="angleType">
<xsd:choice>
<xsd:element name="angleQuantity" type="pef:quantityType"/>
<xsd:element name="dms" type="pef:dmsType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="dmsType">
<xsd:sequence>
<xsd:element name="degree">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="pef:degval">
<xsd:attribute name="direction">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="N"/>
<xsd:enumeration value="E"/>
<xsd:enumeration value="S"/>
<xsd:enumeration value="W"/>
<xsd:enumeration value="+"/>
<xsd:enumeration value="-"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="minute" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:nonNegativeInteger">
<xsd:maxExclusive value="60"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="second" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0.0"/>
<xsd:maxInclusive value="60.0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="degval">
<xsd:restriction base="xsd:nonNegativeInteger">
<xsd:maxInclusive value="180"/>
</xsd:restriction>
</xsd:simpleType>
XML Example:
<greenwich_longitude>
<angle>
<dms>
<degree direction="E">23</degree>
<minute>42</minute>
<second>58.815</second>
</dms>
</angle>
</greenwich_longitude>
--OR--
<greenwich_longitude>
<angle>
<angleQuantity uom="#dega">23.7163375</angleQuantity>
</angle>
</greenwich_longitude>
Point: A point is a location and a set of properties at that location.
XML Schema:
<xsd:complexType name="pointElement">
<xsd:sequence>
<xsd:element name="point" type="pef:pointType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="pointType">
<xsd:sequence>
<xsd:element name="location" type="pef:locationType"/>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="propertyReal">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="propertyKind-ref" type="pef:reference"/>
<xsd:element name="coordAxis-ref" minOccurs="0" type="pef:reference"/>
<xsd:element name="quantityValue" type="pef:quantityType"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="propertyString">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="propertyKind-ref" type="pef:reference"/>
<xsd:element name="string" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
XML Example: (some core properties from a depth of 8726 ft, MD)
<core_sample_description>
<point>
<location>
<coordinateSystem>
<instance-ref refTo="wellMDsystem"/>
</coordinateSystem>
<coordinates>
<value uom="#ft">8726</value>
</coordinates>
</location>
<propertyReal>
<propertyKind-ref refTo="pressure"/>
<quantityValue uom="#psi">4253</quantityValue>
</propertyReal>
<propertyString>
<propertyKind-ref refTo="color"/>
<string>dark brown</string>
</propertyString>
<propertyReal>
<propertyKind-ref refTo="salinity"/>
<quantityValue uom="#ppm">117000</quantityValue>
</propertyReal>
</point>
</core_property_description>
In order to handle the line, surface, and volume types, it is useful to introduce the schema definitions of the following complexTypes: geometryFrame, propertyFrame, leafFrame, descriptor, valuelist.
XML Schema
<xsd:complexType name="geometryFrame">
<xsd:sequence>
<xsd:element name="coordinateSystem" type="pef:instanceElement"/>
<xsd:element name="gridDescription">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="grid-ref" type="pef:reference"/>
<xsd:element name="descriptor" type="pef:descriptor" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="vertex-ref" type="pef:reference" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="detailedType" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="propertyFrame">
<xsd:sequence>
<xsd:element name="gridDescription">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="grid-ref" type="pef:reference"/>
<xsd:element name="descriptor" type="pef:descriptor" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="grid2-ref" type="pef:reference" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="detailedType" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="leafFrame">
<xsd:sequence>
<xsd:choice>
<xsd:element name="propertyKind-ref" type="pef:reference"/>
<xsd:element name="coordAxis-ref" type="pef:reference"/>
<xsd:element name="propertySet-ref" type="pef:reference"/>
</xsd:choice>
<xsd:element name="uomRef" type="pef:unitref"/>
<xsd:element name="listOfValues" type="pef:valuelist"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="descriptor">
<xsd:attribute name="lowerBound" type="xsd:positiveInteger" default="1"/>
<xsd:attribute name="count" type="xsd:positiveInteger" use="required"/>
<xsd:attribute name="storageOrder" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
<xsd:simpleType name="valuelist">
<xsd:list itemType="xsd:double"/>
</xsd:simpleType>
<xsd:complexType name="stringlist">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="delimiter" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
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.
XML Schema:
<xsd:complexType name="lineElement">
<xsd:sequence>
<xsd:element name="line" type="pef:lineType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="lineType">
<xsd:sequence>
<xsd:element name="geometryFrame" type="pef:geometryFrame"/>
<xsd:element name="leafFrame" type="pef:leafFrame" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
XML Example:
A line, embedded in a 2D coordinate system referenced by CS18, and defined
elsewhere in the document. There are twelve points:
(12936.3, 81127.4)
(12953.2, 81142.5)
(12970.1, 81157.6)
(12987.0, 81172.6)
(13004.0, 81187.7)
(13020.9, 81202.8)
(13037.8, 81217.8)
(13054.7, 81232.9)
(13071.6, 81238.0)
(13088.6, 81253.1)
(13105.5, 81268.1)
(13122.4, 81283.2)
<data_value>
<line>
<geometryFrame detailedType="FT_LINE">
<coordinateSystem>
<instance-ref refTo="CS18"/>
</coordinateSystem>
<gridDescription>
<grid-ref refTo="GR18"/>
<descriptor storageOrder="1" count="12"/>
</gridDescription>
</geometryFrame>
<leafFrame>
<coordAxis-ref refTo="AX18-1"/>
<uomRef 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"/>
<uomRef 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 81283.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.
<xsd:complexType name="surfaceElement">
<xsd:sequence>
<xsd:element name="surface">
<xsd:complexType>
<xsd:choice>
<xsd:element name="gridSurface" type="pef:gridSurfaceType"/>
<xsd:element name="contourSurface" type="pef:contourSurfaceType"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="gridSurfaceType">
<xsd:sequence>
<xsd:element name="geometryFrame" type="pef:geometryFrame"/>
<xsd:element name="leafFrame" type="pef:leafFrame" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="contourSurfaceType">
<xsd:sequence>
<xsd:element name="propertyKind-ref" type="pef:reference"/>
<xsd:element name="uomRef" type="pef:unitref"/>
<xsd:element name="isoLine" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="isoValue" type="xsd:double"/>
<xsd:element name="line" type="lineType"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
XML Example:
A surface, embedded in a 3D coordinate system referenced by STlocal, and defined
elsewhere in the document. The surface is intended to represent a formation top.
There are twelve points, arranged in a 3X4 grid:
(62.5, 12.9, -3618) (69.7, 88.4, -3602) (76.8, 163.9, -3592)
(112.8, 12.7, -3601) (120.0, 88.2, -3591) (127.2, 163.7, -3588)
(162.0, 12.5, -3594) (169.2, 88.0, -3583) (177.5, 163.5, -3582)
(212.4, 12.3, -3606) (219.6, 87.8, -3582) (227.8, 163.3, -3590)
<data_value>
<surface>
<gridSurface>
<geometryFrame detailedType="FT_SURFACE">
<coordinateSystem>
<instance-ref refTo="STlocal"/>
</coordinateSystem>
<gridDescription>
<grid-ref refTo="GR21"/>
<descriptor storageOrder="1" count="4"/>
<descriptor storageOrder="2" count="3"/>
</gridDescription>
</geometryFrame>
<leafFrame>
<coordAxis-ref refTo="AX21-1"/>
<uomRef refTo="#m"/>
<listOfValues>62.5 69.7 76.8
112.8 120.0 127.2
162.0 169.2 177.5
212.4 219.6 227.8
</listOfValues>
</leafFrame>
<leafFrame>
<coordAxis-ref refTo="AX21-2"/>
<uomRef refTo="#m"/>
<listOfValues>12.9 88.4 163.9
12.7 88.2 163.7
12.5 88.0 163.5
12.3 87.8 163.3
</listOfValues>
<leafFrame>
<coordAxis-ref refTo="AX21-3"/>
<uomRef refTo="#ftUS"/>
<listOfValues>-3618 -3602 -3592
-3601 -3591 -3588
-3594 -3583 -3582
-3606 -3582 -3590
</listOfValues>
</leafFrame>
</gridSurface>
</surface>
</data_value>
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. See above for the schema.
XML Example: Contour of the above surface
<data_value>
<surface>
<contourSurface>
<propertyKind-ref refTo="elevation"/>
<uomRef refTo="ftUS"/>
<isoLine>
<isoValue>-3610</isoValue>
<line>
<geometryFrame detailedType="FT_LINE">
<coordinateSystem>
<instance-ref refTo="CS20"/>
</coordinateSystem>
<gridDescription>
<grid-ref refTo="GRline"/>
<descriptor storageOrder="1" count="2"/>
</gridDescription>
</geometryFrame>
<leafFrame>
<coordAxis-ref refTo="AX20-1"/>
<uomRef refTo="#ftUS"/>
<listOfValues>65.9 87.6</listOfValues>
</leafFrame>
<leafFrame>
<coordAxis-ref refTo="AX20-2"/>
<uomRef refTo="#ftUS"/>
<listOfValues>53.8 12.9</listOfValues>
</leafFrame>
</line>
</isoLine>
<isoLine>
<isoValue>-3600</isoValue>
<line>
<geometryFrame detailedType="FT_LINE">
<coordinateSystem>
<instance-ref refTo="CS20"/>
</coordinateSystem>
<gridDescription>
<grid-ref refTo="GRline"/>
<descriptor storageOrder="1" count="4"/>
</gridDescription>
</geometryFrame>
<leafFrame>
<coordAxis-ref refTo="AX20-1"/>
<uomRef refTo="#ftUS"/>
<listOfValues>70.2 117.0 188.4 214.1 </listOfValues>
</leafFrame>
<leafFrame>
<coordAxis-ref refTo="AX20-2"/>
<uomRef refTo="#ftUS"/>
<listOfValues>95.3 12.7 12.2 24.5</listOfValues>
</leafFrame>
</line>
</isoLine>
<isoLine>
<isoValue>-3590</isoValue>
<line>
<geometryFrame detailedType="FT_LINE">
<coordinateSystem>
<instance-ref refTo="CS20"/>
</coordinateSystem>
<gridDescription>
<grid-ref refTo="GRline"/>
<descriptor storageOrder="1" count="5"/>
</gridDescription>
</geometryFrame>
<leafFrame>
<coordAxis-ref refTo="AX20-1"/>
<uomRef refTo="#ftUS"/>
<listOfValues>84.9 124.8 166 221.5 227.8</listOfValues>
</leafFrame>
<leafFrame>
<coordAxis-ref refTo="AX20-2"/>
<uomRef refTo="#ftUS"/>
<listOfValues>164.0 112.2 53.1 134.2 163.3</listOfValues>
</leafFrame>
</line>
</isoLine>
</contourSurface>
</surface>
</data_value>
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.
XML Schema
<xsd:complexType name="volumeElement">
<xsd:sequence>
<xsd:element name="volume" type="pef:volumeType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="volumeType">
<xsd:sequence>
<xsd:element name="geometryFrame" type="pef:geometryFrame"/>
<xsd:element name="leafFrame" type="pef:leafFrame" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
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.
XML Schema
<xsd:complexType name="elementElement">
<xsd:sequence>
<xsd:element name="element" type="pef:elementType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="elementType">
<xsd:sequence>
<xsd:element name="propertyFrame" type="pef:propertyFrame"/>
<xsd:element name="leafFrame" type="pef:leafFrame" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
XML Example:
For each of the 12 points in the surfaceGrid (surface example), there are assigned
a porosity and a seismic amplitude.
<data_value>
<element>
<propertyFrame detailedType="EGRID_2DNODE">
<gridDescription>
<grid-ref refTo="GR21"/>
<descriptor storageOrder="1" count="4"/>
<descriptor storageOrder="2" count="3"/>
</gridDescription>
</propertyFrame>
<leafFrame>
<propertyKind-ref refTo="porosity"/>
<uomRef refTo="#Euc"/>
<listOfValues>.13 .12 .10 .18 .16 .14
.17 .16 .13 .17 .15 .15
</listOfValues>
</leafFrame>
<leafFrame>
<propertyKind-ref refTo="seisamp"/>
<uomRef refTo="#Euc"/>
<listOfValues>1.86 1.82 1.03 2.44 2.03 1.28
2.49 2.62 2.03 2.33 1.94 1.88
</listOfValues>
</leafFrame>
</element>
</data_value>
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.
XML Schema:
<xsd:complexType name="sampleElement>
<xsd:sequence>
<xsd:element name="sample" type="pef:sampleType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="sampleType">
<xsd:sequence>
<xsd:element name="descriptor" type="descriptor"/>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="propertyReal">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="propertyKind-ref" type="reference"/>
<xsd:element name="uom-ref" minOccurs="0" type="reference"/>
<xsd:element name="listOfValues" type="valuelist"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="propertyString">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="propertyKind-ref" type="reference"/>
<xsd:element name="listOfStrings" type="stringlist"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
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 modelled as keu and keyref 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.
XML Schema:
<xsd:complexType name="unstructured_3d_topologyElement">
<xsd:sequence>
<xsd:element name="a3dnode" type="pef:3dnodeType" maxOccurs="unbounded">
<xsd:unique name="dummy3dn">
<xsd:selector xpath="."/>
<xsd:field xpath="@id"/>
</xsd:unique>
<xsd:key name="a3dnoderef">
<xsd:selector xpath="."/>
<xsd:field xpath="@id"/>
</xsd:key>
</xsd:element>
<xsd:sequence minOccurs="0">
<xsd:element name="a3dedge" type="pef:3dedgeType" maxOccurs="unbounded">
<xsd:unique name="dummy3de">
<xsd:selector xpath="."/>
<xsd:field xpath="@id"/>
</xsd:unique>
<xsd:key name="a3dedgeref">
<xsd:selector xpath="."/>
<xsd:field xpath="@id"/>
</xsd:key>
<xsd:keyref name="dummy3de2" refer="pef:3dnoderef">
<xsd:selector xpath="*"/>
<xsd:field xpath="@refTo"/>
</xsd:keyref>
</xsd:element>
<xsd:sequence minOccurs="0">
<xsd:element name="a3dface" type="pef:3dfaceType" maxOccurs="unbounded">
<xsd:unique name="dummy3df">
<xsd:selector xpath="."/>
<xsd:field xpath="@id"/>
</xsd:unique>
<xsd:key name="a3dfaceref">
<xsd:selector xpath="."/>
<xsd:field xpath="@id"/>
</xsd:key>
<xsd:keyref name="dummy3df2" refer="pef:3dedgeref">
<xsd:selector xpath="*"/>
<xsd:field xpath="@refTo"/>
</xsd:keyref>
</xsd:element>
<xsd:element name="a3dcell" type="pef:3dcellType" minOccurs="0" maxOccurs="unbounded">
<xsd:unique name="dummy3dc">
<xsd:selector xpath="."/>
<xsd:field xpath="@id"/>
</xsd:unique>
<xsd:key name="a3dcellref">
<xsd:selector xpath="."/>
<xsd:field xpath="@id"/>
</xsd:key>
<xsd:keyref name="dummy3dc2" refer="pef:3dfaceref">
<xsd:selector xpath="*"/>
<xsd:field xpath="@refTo"/>
</xsd:keyref>
</xsd:element>
</xsd:sequence>
</xsd:sequence>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="a3dnodeType">
<xsd:sequence>
<xsd:element name="location" type="pef:locationType" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
<xsd:complexType name="a3dedgeType">
<xsd:sequence>
<xsd:element name="hasNode" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="refTo" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="centerNode" minOccurs="0">
<xsd:complexType>
<xsd:attribute name="refTo" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
<xsd:complexType name="a3dfaceType">
<xsd:sequence>
<xsd:element name="hasEdge" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="refTo" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="centerNode">
<xsd:complexType>
<xsd:attribute name="refTo" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="adjacentFace">
<xsd:complexType>
<xsd:attribute name="refTo" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
<xsd:complexType name="a3dcellType">
<xsd:sequence>
<xsd:element name="hasFace" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="refTo" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="centerNode" minOccurs="0">
<xsd:complexType>
<xsd:attribute name="refTo" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:positiveInteger" use="required"/>
</xsd:complexType>
XML Example:
<unstructured_3d_topology>
<a3dnode id="1">
<location>
<coordinateSystem>
<instance-ref refTo="somelocalsystem"/>
</coordinateSystem>
<coordinates>
<value uom="#ft">0.</value>
<value uom="#ft">0.</value>
<value uom="#ft">0.</value>
</coordinates>
</location>
</a3dnode>
<a3dnode id="2">
<location>
<coordinateSystem>
<instance-ref refto="somelocalsystem"/>
</coordinateSystem>
<coordinates>
<value uom="#ft">1.</value>
<value uom="#ft">0.</value>
<value uom="#ft">0.</value>
</coordinates>
</location>
</a3dnode>
<a3dnode id="3">
<location>
<coordinateSystem>
<instance-ref refTo="somelocalsystem"/>
</coordinateSystem>
<coordinates>
<value uom="#ft">0.</value>
<value uom="#ft">1.</value>
<value uom="#ft">0.</value>
</coordinates>
</location>
</a3dnode>
<a3dnode id="4">
<location>
<coordinateSystem>
<instance-ref refTo="somelocalsystem"/>
</coordinateSystem>
<coordinates>
<value uom="#ft">0.</value>
<value uom="#ft">0.</value>
<value uom="#ft">1.</value>
</coordinates>
</location>
</a3dnode>
<a3dedge id="1">
<hasNode refTo="1"/>
<hasNode refTo="2"/>
</a3dedge>
<a3dedge id="2">
<hasNode refTo="1"/>
<hasNode refTo="3"/>
</a3dedge>
<a3dedge id="3">
<hasNode refTo="1"/>
<hasNode refTo="4"/>
</a3dedge>
<a3dedge id="4">
<hasNode refTo="2"/>
<hasNode refTo="3"/>
</a3dedge>
<a3dedge id="5">
<hasNode refTo="2"/>
<hasNode refTo="4"/>
</a3dedge>
<a3dedge id="6">
<hasNode refTo="3"/>
<hasNode refTo="4"/>
</a3dedge>
<a3dface id="1">
<hasEdge refTo="1"/>
<hasEdge refTo="2"/>
<hasEdge refTo="4"/>
</a3dface>
<a3dface id="2">
<hasEdge refTo="1"/>
<hasEdge refTo="3"/>
<hasEdge refTo="5"/>
</a3dface>
<a3dface id="3">
<hasEdge refTo="2"/>
<hasEdge refTo="3"/>
<hasEdge refTo="6"/>
</a3dface>
<a3dface id="4">
<hasEdge refTo="4"/>
<hasEdge refTo="5"/>
<hasEdge refTo="6"/>
</a3dface>
<a3dcell id="1">
<hasFace refTo="1"/>
<hasFace refTo="2"/>
<hasFace refTo="3"/>
<hasFace refTo="4"/>
</a3dcell>
</unstructured_3d_topology>
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 defined in the Data Exchange Standard. Their definitions will not be repeated here.
The objects are modelled in the Data Exchange Standard in Express, and are subject to the same rules as above for generating the XML tags. These objects will therefore be generated using the same rules as given above with the following exceptions:
The POSC Exchange File will consist of a root Tag, followed by the PEF Objects, followed by the Exchange Set. In addition, there will be a section in the file for units of measure, and other outside reference information, if needed.
XML Schema for the main application
<xsd:element name="PEFExchange">
<xsd:complexType>
<xsd:sequence>
<element ref="PEFObjects" minOccurs="0"/>
<element name="UomBlock" type="uomBlockEntry"/>
<element ref="ExchangeData"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
The PEFObjects and ExchangeData are defined as:
XML Schema:
<xsd:element name="PEFObjects">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="DAE_DATA_SET_HEADER" minOccurs="0"/>
<xsd:element name="DAE_DATA_STORE_ROOT" minOccurs="0"/>
<xsd:element name="DAE_DATA_EXCHANGE_PROFILE" minOccurs="0"/>
<xsd:element name="DAE_EXPORT_DESCRIPTOR" minOccurs="0"/>
<xsd:element name="DAE_IMPORT_DESCRIPTOR" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ExchangeData">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ENTITY" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
The DAE_xxx elements will be specifically defined in the total XML Schema. These definitions are not normative, and will not be given here.
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.