Reference Data and Enumerated List

Implemented in XML¹

John I. Bobbitt

POSC

bobbitt@posc.org

Abstract: XML Schemas contain enumerated lists that allow the allowed values to be restricted. Rules and procedures should be set that allow extensions to these lists to be made in a consistent way. The extensions should be made, if at all possible, when the XML instance document is being developed. It is also advisable that the values and their meanings be accessible to readers and writers of XML documents.

1.Usage: Fixed List

1.1.Non-extendable

An element or attribute has a fixed list of values it can assume. For example, an answer to a question may be either “yes” or “no”. A depth may be either “MD” or “TVD”. A currency is one of a long, but finite list of ISO abbreviations.

The reasons for wanting to restrict to a fixed list are

1. The Reading implementation has a known set of cases to consider.

2. Variations in spelling, abbreviating, case are eliminated. For example, the user can only answer “yes”. Variations such as “Yes”, “YES”, and “y”, which mean the same, are not permitted.

Implementation is easy for this case. An enumerated list is the choice.

<xsd:simpleType name=”depthType” final=”#all2”>
  <xsd:restriction base=”xsd:string”>
    <xsd:enumeration value=”MD”/>
    <xsd:enumeration value=”TVD”/>
  </xsd:restriction>
</xsd:simpleType>

1.1.1.Discussion

The list is not extendable. The above construction should only be used where it is clear that the list should be tightly controlled, and only extended as a new version

1.1.2.Extending the List

If a user community needs to extend the list, they must copy and build their own schema, with the simpleType as above containing the new set of values. This is not recommended, because extending the list is not considered a valid extension, and breaks interoperability by introducing values that are not expected by readers and are not flagged as extensions.

1.1.3.Policy and Practice

When the usage case is that the list should be fixed, build a simpleType using enumeration of the values. The elements and attributes that use the values should be local. Extension (or further restrictions) of the set of values should be done by POSC (or the owning community) with a change in version.

1.2.Extendable Fixed Lists

The terms ‘extendable fixed’ are contradictory. However, there is a common usage case that we will place under this situation. This is the case in which the list is fixed, but allows ‘other’ to be specified. For this case, there is no semantic meaning to the value of ‘other’ except that it states that the given list of values has none that are appropriate. Also common is the addition of ‘unknown’.

For example, a list of drilling environement may include {land, offshore, other}. If the drilling occurs in a tidal marsh, the instance writer may not want to use either land or offshore, and therefore can choose ‘other’ as the value. Note that this selection does not convey any information about the environment.

1.2.1.Discussion

The two values, other and unknown, are often attached to a fixed list if it is appropriate to add them. It should be determined on a case by case basis which, if not both, of these are appropriate.

The semantic meaning of the two values is different. ‘other’ generally means that there is an appropriate value, but it is not in the list of values that are given. ‘unknown’ means that the instance writer does not know the value.

Additional cases will be considered in the following sections. The particular cases to be considered are (1) Give a qualifier to ‘other’ to more fully describe it, and (2) Allow the instance writer to give a refinement of the listed values. An example of case 2 would be if the writer had to select status from {drilling, producing, shut-in}, and wanted to say that the status was ‘fishing’, which is drilling, but a bit more specific.³

1.2.2.Policy and Pactice

When a fixed list may not be inclusive of all possible values, include the value, ‘other.’

When a fixed list is part of a mandatory element or attribute, consider including the value ‘unknown.’

2.Extendable Lists

With the fixed list cases, we are telling the writer that we have a pretty good list of values to choose from, and we are not expecting additional values. With extendable lists, we are telling the writer that we are giving a good starting set of values, but we are allowing the list to be extended. In doing this, we must provide ways to extend the list with very simple mechanisms.

POSC has developed a tight procedure for handling lists of this type. The particular methods allow additional values to be added without having to alter or extend the schema. I.e., the additional values may be added at XML-write time. The procedure will be explained in the remainder of this section.

2.1.General extendable lists

The 1.2 section allows the value ‘other’ to be the extension policy. While this allows the writer to say that there is a value, other than those in the enumerated list that is appropriate, it does not allow him to say what the value is. This can be done in by introducing a choice, ‘Other: xxx’.

2.1.1.Extension by Other: method

First, define a value which has the pattern ‘Other: xxx’, where xxx represents two or more characters:

<xsd:simpleType name=”otherNameType”>
  <xsd:restriction base=”xsd:string”>
    <xsd:pattern value=”Other: \w{2,}”/>
  </xsd:restriction>
</xsd:simpleType>

Then make this a union with the simple type which is the enumerated list. For example, the depthType illustrated above can be extended by

<xsd:simpleType name=”extDepthType”>
  <xsd:union memberTypes=”depthType otherNameType”/>
</xsd:simpleType>

It is also possible, and possibly more desirable, to include the pattern facet with the original enumerated values. Thus, an equivalent form of extDepthType would be:

<xsd:simpleType name=”extDepthType”>
  <xsd:restriction base=”xsd:string”>
    <xsd:enumeration value=”MD”/>
    <xsd:enumeration value=”TVD”/>
    <xsd:pattern value=”Other: \w{2,}”/>
  </xsd:restriction>
</xsd:simpleType>

POSC has defined the otherNameType in its basic components, and forms the extended type of all its lists using the union⁴.

2.1.2.Discussion

This allows the writer to use ‘MD’, ‘TVD’, or ‘Other: xxx’, where xxx can be any string of 2 or more characters. While it does not define the meaning of the xxx, it does allow an extension of the values at XML write time. When a group can agree on the meanings of the extended values, this offers a method for incorporating these extended values without having to change the schema.

Another advantage is that the ‘Other: ‘ portion offers a flag to the reading application. If the reading application sees this string, it is aware that an extension is present, and can take the appropriate action. If this pattern is used consistently in POSC, it becomes a standard pattern for the reader.

Since this is a simple type, it can be used as either an element value or an attribute value.

2.1.3.Policy and Practice

When there is a preferred list of values, and it is preferred to have a non-schema extension that is understood within a community, form a simple type which includes the “Other: xx” possibility as shown above.

2.2.General Refinement attribute

It may be useful to allow a class to have a refinement. The usage case is that the schema provides a preferred list of values, possibly with an extension method (as described in 2.1 above). However, the schema also wants the writer to be able to refine the value.

This occurs mainly in two cases. In the first case, POSC (i.e., the schema developer) does not wish to build a deep hierarchy of class values. With well status, for example, POSC has decided not to refine the meaning of ‘drilling’ to a lower level, because this would lead to too many values, with too fine a distinction.

The second case is where the refinements are not agreed upon. For example, when trying to develop a list of refinements to ‘drilling,’ it may not be possible to get companies and agencies to agree on what the values are, and what their meanings are.

In either case, though, the writer (and reader) of the XML instance file may wish to refine a value in an enumerated list. In this case, it should be required that both the value in the list, and the refinement be given. Below are examples of how this would look for both an element and an attribute:

<WellStatus refinement=”fishing”>drilling</WellStatus>
<Carbonate kind=”skeletal” refinement=”mollusk”/>

2.2.1.Proposed Method

Add an additional attribute, ‘refinement’, to the element or attribute which has a controlled list. The refinement attribute should be an uncontrolled string.

Below are shown the two methods for doing this, which cover the two examples above.

<xsd:complexType name=”refinedStatusValueType”>
 <xsd:simpleContent>
  <xsd:extension base=”statusValueType”> .. this is the enumerated list
   <xsd:attribute name=”refinement” type=”xsd:string”/>
  </xsd:extension>
 </xsd:simpleContent>
</xsd:complexType>

<xsd:complexType name=”refineCarbonateType”>
 <xsd:attribute name=”kind” type=”statusValueType”/>
 <xsd:attribute name=”refinement” type=”xsd:string”/>
</xsd:complexType>

2.2.2.POSC Selected Method for Refinement

POSC implements the first of the two choices for its enumerated lists. All enumerated lists that allow refinements use the element value, with refinement attribute method.

2.2.3.Discussion

The purpose is to give a common way to do the refinement. This is done by introducing the ‘refinement’ attribute. The element which gives the value is to contain this attribute.

Note that the refinement attribute satisfies two conditions. First, it requires that the writer give the parent class from the preferred list. Secondly, it acts as a flag which tells the reader that this is a refinement of a given class, and not a whole new class.

2.2.4.Policy and Practice

The attribute, ‘refinement’, should be attached to the element or attribute which has the restricted list of values.

POSC best practices would prefer the “element” method of refinement (refinedStatusValueType), in which the attribute, refinement, relates to the value of the element. The use of the two attribute method (refineCarbonateType) is discouraged.

3.Variable Lists

The previous sections have dealt with a fixed, or a preferred list of values. Another use case is where we must make it possible for those exchanging the information to choose their own list of values. This is also useful in the cases where the list is owned and maintained by another group (such as ISO country codes), or if a list changes frequently.

While POSC has developed standard practices for handling the cases of sections 1 and 2, it has not developed a best practice for this case. This section is still open for discussion.

There are three requirements that come to the fore in this area: What is the list? What are the values in the list? What is the meaning of the values?

With each method of handling variable lists, these questions must be explored, if not answered. Hence, each of the methods below will give a discussion of how well the approaches answer these questions.

In addition, it is important to know if the method is extendable within the schema, or if the schema itself needs extending. If the schema needs to be extended, what are the steps to extend it? And can the extension be done remotely, in an application schema namespace, or must it be done by the original schema developer, by altering the existing schema (can it be done by extension or restriction, or must it be done by alteration)?

3.1.Name, NamingSystem⁵

A naming system can often define the list of names (values, or codes) that are in the naming system. Often, the values in the list are implicit. For example, API numbers and Social Security Numbers are naming systems that implicitly define the set of values within their system. However, the list may also be explicit. The ISO currency codes are an explicitly set of code values (3 character) which identify every national currency.

The assumption for this method is that the naming system and the values in the naming system are mutually understood by the reading and writing applications. The understanding may occur by mutual agreement, by national or international standards, by explicit descriptions in a written document, or by some other means. The understanding will not occur in the XML instance file itself. The method is merely a way for the writing application to say, “I am giving you this value, as defined in this naming system.” There is no attempt with this method to define the naming system or the values in this naming system.

This method may be implemented in three basic ways: two attribute, attribute-element, two element⁶. The particular implementation depends on the other information that can be carried with the group. Below are XML instance examples of the three methods:

Two attribute:
<WellName name=”123456798000” namingSystem=”API”/>

Attribute-element:
<WellName namingSystem=”API”>123456789000</WellName>

Two element:
<WellName>
  <Name>123456789000</Name>
  <NamingSystem>API<NamingSystem>
</WellName>

3.1.1.Implementations

Two attribute (using free text for namingSystem)
<xsd:element name=”WellName”>
 <xsd:complexType>
  <xsd:attribute name=”name” type=”xsd:string” use=”required”/>
  <xsd:attribute name=”namingSystem” type=”xsd:string” use=”required”/>
  <xsd:attribute name=”version” type=”xsd:string” use=”optional”/>
 </xsd:complexType>
</xsd:element>

Attibute-element (using free text for namingSystem)
<xsd:element name=”WellName”>
 <xsd:complexType>
  <xsd:simpleContent>
   <xsd:extension base=”xsd:string”>
    <xsd:attribute name=”namingSystem” type=”xsd:string” use=”required”/>
    <xsd:attribute name=”version” type=”xsd:string” use=”optional”/>
   </xsd:extension>
  </xsd:simpleContent>
 </xsd:complexType>
</xsd:element>

Two element (using free text for NamingSystem)
<xsd:element name=”WellName”>
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name=”Name” type=”xsd:string”/>
   <xsd:sequence minOccurs=”0”>
     <xsd:element name=”NamingSystem” type=”xsd:string”/>
     <xsd:element name=”Version” type=”xsd:string” minOccurs=”0”/>
   </xsd:sequence>
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>

3.1.2.Discussion

This paper does not recommend any of these over the others. Some of the considerations in choosing are:

• Two element is most easily extended. For example, it is easy to add a Description to the group.

• POSC Best Practices discourage the use of the two attribute method, since we encourage the data to be carried by an element, and the attributes be used to qualify the value. Two attribute and attribute-element carry the concept of a datatype. The value is closely tied to the naming system. The values are tightly tied together within a single element.

• The 'Name' must be free text. The 'namingSystem may' be free text, or it may be controlled.

The three questions:

What is the list? This is answered by the namingSystem attribute or element. The namingSystem may be controlled by an enumerated list, or it may be free text.

What are the values in the list? This is answered only by knowledge of the list. The actual values in the list may be implicitly known (eg, API number), or they may be assumed to be known by the reading application. Since the namingSystem controls which list is picked, the values in the list may not be enumerated.

What is the meaning of the values? The definition of each value must be given in an outside document⁷ which is not available to the XML reader. Additional information will be supplied in further methods (below) which can point the reader to such a definition list.

Extensions: Additional information

The schema owners can alter the set of information in either of the above three implementations. Remote schemas cannot extend the set of information very easily. Structures in the following sections will be given to make this extendable.

In general, there should be no extensions to the schema. If additional information is necessary or desirable, this information should be in the original schema.

Since the lists for a naming system and their values are not controlled by the schemas, it is up to the controllers of the lists to control them. It is very easy to extend a list, when it is located at your local site. However, it must be understood by the community of users that such an extension may cause problems with reading applications.

Extensions: Other list

There should be no need for any extensions in the values for naming systems. If there is an enumerated list of values for the naming system, the extension of this list of values should be handled as given in sections 1 and 2.

3.2.Dictionaries of Values

The previous methods of sections 1 and 2 used enumerated lists to develop a controlled set of values. In every case, it is up to the reader and writer to understand the values in the list.

An alternative method is to give a value and standardize on a method for giving the meaning of the value. Here is an example of how that might look:

<WellStatus namingSystem=”GoodOil” valueRef=”statusfile”>
     Progressive working</WellStatus>

In this example, the reference to “statusfile” will lead the reader to a place where it can find the definition of the element value, ‘Progressive working.’

Note that this method is the same as the Name, NamingSystem method (section 3.1) with the addition of the valueRef attribute. This attribute can be attached to the Name, NamingSystem methods and made optional. It is useful to agree on a single name for this attribute. The proposed name is ‘valueRef’.

The usefulness of this method depends on usefulness of the reference. At a minimum, the reference definition can contain a “description” of the value. It may also contain machine interpretable information that could be used in processing the file. An example of this is the units of measure document which gives the conversion formula for the referenced unit, and can be processed by the reading application.

Owned by other organizations:

Similar in implementation is the need to use a standard list that is maintained by other organizations. For example, there is a list of 2 character country codes maintained by ISO. They also have a 3 character code, a three digit code, and a standard name. Other groups also have country codes, such as the FIPS codes maintained by the US.

In all of these cases, it is necessary to give the list that is being used, as well as the code value. An example would be:

<Country namingSystem=”ISO 3 character”>USA</Country>

When implementing this, it is necessary for the community of users to agree on the permitted lists, and how to define the list being used (ie., the values of namingSystem). In particular, it may be necessary to control the namingSystem values using an enumerated list, so that the specification of the code list systems are controlled.

3.2.1.Implementation

Add an additional attribute, ‘valueRef’, to the appropriate element. The value of ‘valueRef’ leads to a file (probably through a skip reference) that contains the definition of the element value. The file reference, combined with the element value, will lead to this specific information.

In the example, the attribute, valueRef, leads us to another element, whose key value is ‘statusfile’. It may look like the following:

<SkipReference id=”statusfile” 
      valueRef=http://www.posc.org/refs/goodoil.xml/>

The reference file may have an element whose name is ‘Progressive working’, and will contain a description and other information.

Alternatively, the statusfile may lead to an element which defines the item within the file:

<StatusDefinition id=”statusfile”>
 . . .
 <Value>
  <Name>Progressive working</Name>
  <Description>. .Some kind of definition . . </Description>
  <Parent href=”otherstatus”/>
   . . .
 </Value>
 . . . (other values)
</StatusDefinition>

The purpose of this section is not to define the structure of the definition, but to standardize on the method for getting to the definition.

3.2.2.Discussion

This method is an add-on to the methods discussed in section 3.1. It allows the reader to access the definition of the value in a standard way. It does not standardize on the actual definitions, or on the elements in the definition file.

This can be combined with other methods.

The usage case requires an additional file or definition element that can be referenced. If it is only desired that the definition be carried in a text document, this method should not be used.

The Three Questions.

What is the list? This is determined by the reference to the value. Presumably, the document containing the values identifies, in one way or another, the list of values that is being used. However, it is quite possible to have multiple lists that can be accessed.

What are the values in the list? For each list, the values on the list are presumably those in the document relating to the list. However, since multiple lists can be used, the values can come from different lists.

What is the meaning of the values? This method has the best availability of the meanings of the values, since the meanings are carried in the referenced document.

3.3.Substitution Group Replacement

It is possible to add an extension capability that will allow the developers of the application schema to substitute one or more alternate lists to the ones chosen. In this case, POSC will provide an enumerated lists as was done in Sections 1 or 2, but also allow the user to replace the list.

This is done by setting up an abstract, empty type, that serves as the head of a substitution group. POSC supplies one (or more) nonabstract lists for this element.

The following process will be used to implement this method.

Step 1: Develop an abstract element of type, string, to serve as the head element:

<element name=”_WellPurpose” type=”string” abstract=”true”/>

Step 2: Incorporate this element into the schema being developed.

<complexType name=”someModuleBeingDeveloped”>
  <sequence>
    . . . some elements. And finally...
    <element ref=”_WellPurpose”/>
    . . . and more of the module . . .
  </sequence>
</complexType>

Step 3: Create an enumerated list a restriction of the abstract entity's datatype. In this case, the datatype would be a restriction of “string”.

<simpleType name=”goWellPurposeType”>
  <restriction base=”string”>
    <enumeration value=”firstvalue”/>
    <enumeration value=”secondvalue”/>
      . . .
    <enumeration value=”lastvalue”/>
  </restriction>
</simpleType>

Note: POSC will define zero or more nonabstract elements as part of the substitution group:

<element name=”POSCWellPurpose” type=”A:extWellPurposeEnum” 
        substitutionGroup=”_WellPurpose”/>

The element, Purpose, can be used along with its restricted set of values. (See Section 4 below to understand the derivation and meaning of extWellPurposeEnum). Note that these values are ultimately restrictions (or extensions) from the string type.

Step 4: Define an element in the substition group using the type developed by the other group:

<element name=”GoodOilWellPurpose” type=”B:goWellPurposeType”
        substititionGroup=”_WellPurpose”/>

4.POSC General Practice with Enumerated Lists

POSC will, in general, develop an enumerated list as an XML file. For example:

<EnumeratedList>

  <Name>North Direction</Name>
  <Description>The direction of north in the system measuring a deviation 
        from north.</Description>
  <NamingSystem>POSC</NamingSystem>
  <Version>1.0</Version>

  <Value>
    <Name>true</Name>
    <Description>North, as determined by the direction to the north pole. 
      This is also known as the geographic north.</Description>
  </Value>

  <Value>
    <Name>magnetic</Name>
    <Description>The direction that a magnetic compass points.</Description>
  </Value>

  <Value>
    <Name>grid</Name>
    <Description>The north direction, as defined by the northing or 
     southing in a map projection coordinate reference system.</Description>
  </Value>

  <Value>
    <Name>true calculated</Name>
    <Description>The north direction has been calculated from another 
       north direction. This calculated, true north direction is being
       used.</Description>
  </Value>

  <Value>
    <Name>unknown</Name>
    <Description>It is not known which north direction is being used as 
       the reference direction.</Description>
  </Value>

</EnumeratedList>

This serves as a dictionary that allows users of the schema to determine the meaning of each value in the reference list.

The xml file is used to generate a schema file. A portion is as follows:

  <xsd:simpleType name="northDirEnum">
   <xsd:restriction base="xsd:string">
    <xsd:enumeration value="true"/>
    <xsd:enumeration value="magnetic"/>
    <xsd:enumeration value="grid"/>
    <xsd:enumeration value="true calculated"/>
    <xsd:enumeration value="unknown"/>
   </xsd:restriction>
  </xsd:simpleType>

  <xsd:simpleType name="extNorthDirEnum">
   <xsd:union memberTypes="otherNameType northDirEnum"/>
  </xsd:simpleType>

  <xsd:complexType name="refinedNorthDirEnum">
   <xsd:simpleContent>
    <xsd:extension base="northDirEnum">
     <xsd:attribute name="refinement" type="xsd:string" use="optional"/>
     <xsd:attribute name="valueRef" type="xsd:anyURI" use="optional"/>
    </xsd:extension>
   </xsd:simpleContent>
  </xsd:complexType>

  <xsd:complexType name="refinedExtNorthDirEnum">
   <xsd:simpleContent>
    <xsd:extension base="extNorthDirEnum">
     <xsd:attribute name="refinement" type="xsd:string" use="optional"/>
     <xsd:attribute name="valueRef" type="xsd:anyURI" use="optional"/>
    </xsd:extension>
   </xsd:simpleContent>
  </xsd:complexType>

A schema developer has four types to choose from. When defining an element whose domain is the enumerated list, the schema developer can decide if the need is for a ‘fixed list,’ in which case he will use the northDirEnum⁸. If the need is for a list that can be extended at XML wirte time, he may use the extNorthDirEnum. If the need is for a list that can be refined, he will choose the refinedNorthDirEnum. And if he needs both extension and refinement, he uses refinedExtNorthDirEnum.

The schema as shown above creates the four type, only one of which will generally be used. However, it usage determines that another of the choices is appropriate, it is easy to make the change.

Note that the first two types may be used as attribute values, since they are simple types. The last two, however, are complex types, and may only be used when defining an element.

5.References

5.1.Outside References

[ANSIX12] X12 Reference Model for XML Design, 2002-10, produced by the ANSI X12 committee, obtainable at http://www.x12.org/x12org/.

[BestPractices] Best Practices Homepage, developed and maintained by XML-dev and Mitre, obtainable at http://www.xfront.com/BestPracticesHomepage.html.

[ComProServ] PIDX XML Standards Master, Version 1.0, RP 3901, produced by PIDX, obtainable at http://committees.api.org/business/pidx/standards.htm.

[EBCCNAM] ebXML RT - Naming Convention for Core Component, 2001-05-10, produced by the ebXML group, obtainable at http://www.ebxml.org/specs/index.htm#technical_reports.

[ebTechArch] ebXML Technical Architecture Specification V1.0.4, 2001-02-16, produced by the ebXML group, obtainable at http://www.ebxml.org/specs/ebTA.pdf.

[FedDevGuide] Draft Federal XML Developer's Guide, 2002-04 (work in progress), produced by the Federal CIO Council, obtainable at http://xml.gov/documents/in_progress/developersguide.pdf.

[FedTagStds] Federal Tag Standards for Extensible Markup Language, 2001-06, produced by LMI, not obtainable from the internet.

[HKGuide] XML Schema Design and Management Guide, (4 parts), Draft versions dated in summer, 2003. Produced by Hong Kong Information Services Technology Division. Available at http://www.itsd.gov.hk/itsd/english/infra/eif.htm.

[IETFKeywords] Key Words for Use in RFCs to Indicate Requirement Level, 1997-03, obtainable at http://www.ietf.org/rfc/rfc2119.txt.

[ISO8601] International Standard Date and Time, 2001-11-10, produced by ISO. A web page that explains the formats is http://www.cl.cam.ac.uk/~mgk25/iso-time.html.

[ISO11179] ISO 11179 Part 5 - Naming and Identification, 1995-12, produced by ISO, obtainable at http://fdr.faa.gov/iso/ISO11179page.htm. There is a later version, that is available from the ISO website,

[UKGuide] e-Government Schema Guidelines for XML, 2002-12, produced by United Kingdom e-Envoy, obtainable at http://www.e-envoy.gov.uk/Resources/Guidelines/fs/en.

[Unicode] Unicode Charts, available at http://www.unicode.org/charts/.

[W3CSchemaDatatypes] W3C Schema Datatypes, 2001-05-02, produced by W3C, obtainable at http://www.w3.org/TR/xmlschema-2.

[W3CNamespaces] Namespaces in XML, 1999-01-14, produced by W3C, obtainable at http://www.w3.org/TR/REC-xml-names/.

[W3CSchemaPrimer] W3C Schema Primer, 2001-05-02, produced by W3C, obtainable at http://www.w3.org/TR/xmlschema-0.

[W3CSchemaStructures] W3C Schema Structures, 2001-05-02, produced by W3C, obtainable at http://www.w3.org/TR/xmlschema-1.

[Xlink] W3C XLink Specification, 2001-06, produced by W3C, obtainable at http://www.w3.org/TR/xlink/.

[Xpath] W3C XPath Specification, 1999, produced by W3C, obtainable at http://www.w3.org/TR/xpath/.

[XSL] W3C XSL and XSLT Specifications, produced by W3C, obtainable at http://www.w3.org/Style/XSL/.

5.2.POSC References

POSC references are available in the following formats:

[html] html format readable by browsers

[doc] MS Word 97/2000/XP

[sxw] OpenOffice writer, v1.0

[IntroModule] Introduction to Modules, Copyright 2002-2003. Available in [html], [doc], [sxw].

[BuildModule] Build a Module - a tutorial. Copyright 2003. Available in [html], [doc], [sxw].

[ImportModule] Importing Modules within your Modules. Copyright 2003. Available in [html], [doc], [sxw].

[Guidelines] Guidelines for XML Schemas, Version 2003. Copyright 2003. Available in [html], [doc], [sxw].

[ModulePolicies] Policies on Modules. Copyright 2002-2003. Available in [html], [doc], [sxw].

[ProfilesAppSchema]  Modules, Profiles, and Application Schemas. Copyright 2002-2003. Available in [html], [doc], [sxw].

[XMLTables]  XML Tables. Copyright 2003. Available in [html], [doc], [sxw].

[ReferenceData]  Reference Data and Enumerated Lists Implemented in XML. Copyright 2002-2003. Available in [html], [doc], [sxw].

[Dictionaries]  Examples of XML Dictionary Usage. Copyright 2003. Available in [html], [doc], [sxw]. Accompanied by sample code.

[Relationships] Relationships in XML. Copyright 2003. Available in [html], [doc], [sxw].

[UOMRecs]  Unit of Measure Recommendations. Copyright 2002-2003. Available in [html], [doc], [sxw].

Appendix A.Usage Cases

Case: An absolutely fixed set of values. It is useful to standardize on the look (case, spelling, etc) of this fixed set.

Use Section 1.1.

Example: Depth type is {MD, TVD}.

Case: A fixed set of values for which standardized look and meanings are needed. But there may be cases which do not fit this set.

Use Section 1.2, adding ‘other’ to the list.

There may be cases where the value is unknown. For example, the information is included with legacy data.

Use Section 1.2, adding ‘unknown’ to the list.

Note that unknown may be generalized to include values with other semantics. For example, values in addition to unknown may be withheld, missing, absent, with appropriate meanings attached.

Case: A preferred list of values, with encouragement for communities of users to add additional values to the list.

Use Section 2.1, adding the ‘Other: xxx’ to the list.

Example: Pick type = {top, base}. Allows ‘Other: fluid interface’.

Case: A preferred list of values, developed to a certain level, with encouragement for communities to refine the level with “child” values.

Use Section 2.2, refinement attribute.

Examples: Well status = {. ., drilling, . .}. Allows refinement to add {fishing, pulling out of hole, logging}.

Case: Several lists of values, explicit or implicit, exist. A community should agree on a list to use – the list being specified by a value for a naming system. Different communities may use different lists (and naming systems).

Use Section 3.1, name, naming system, (version).

Examples: {API number, local field name, DTI PONS}, {Social Security number, employee number, full name}, {country names, FIPS, ISO 2 character code}.

Case: The meanings, and other information, of existing or new values should be carried with the document or in an associated document.

Use Section 3.3, valueRef attribute.