WITSML Data Schema Overview

Version 1.3.1.1

(v131 bug-fix)

This document contains the following sections:

• Introduction
• Data object schema design
• Naming convention in schemas
• WITSML Schemas, XML Documents, and Stylesheets

This is a bug fix version of v1.3.1.0. Only minor changes have been made and are itemized in the change detail file. This version should be used for commercial implementations instead of v1.3.1.0.

Version 1.3.1.1 represents an incremental change to version 1.3.0 which is being deprecated. Commercial implementations of v1.3.0 are strongly discouraged by the WITSML Special Interest Group. Data Schema changes between versions 1.3.0 and 1.3.1.1 are summarized in the Change Summary

Backward compatibility concerns has resulted in the creation of an XSL transformation file to convert v1.2 XML files to v1.3.1.1 XML files for a subset of the WITSML objects. Transforms in the reverse direction are also supported. A spreadsheet documents a mapping between the v1.2 and v1.3.1 schemas.

The schemas are defined and viewed as W3C XML Schema files however a spreadsheet which summarizes the content is available.

This overview is non-normative and is not part of the standard.

Introduction

The Wellsite Information Transfer Standard Markup Language (WITSML) is a standard for sending well site information in an XML document format between business partners. XML schemas are used to define the content of an XML document.  The WITSML standard consists of two specifications which will be versioned independently: Data Schema and Application Program Interface (API). This document provides an overview of the Data Schema. The WITSML data schema consists of a set of independent but relatable data object schemas. A data object schema defines a set of data that can be transmitted within a single XML document and represents a cohesive subset (e.g.; well, wellbore, rig, etc.) of an overall logical schema related to a single domain (well). Data object schemas contain attributes, elements, and included component sub-schemas.

Component schemas are XML schemas, but these schemas do not represent complete data objects. A component schema may be included by more than one data object schema. All component schemas are prefixed with (cs_). Each component schema file generally defines one type that has the same name as the file name.

An attribute group file (attgrp_uid.xsd) is used to define a unique identifier (uid) attribute for all recurring container elements. A container element is an element that contains other elements. The uid attribute is optional but is required within the context of a WITSML server. This is the equivalent of a RDBMS system generated primary key.

Low level simplistic types are defined in the following files. Each file defines many types. Each component schema file must directly or indirectly include file typ_dataTypes.xsd. If a component schema includes another component schema then it will be indirectly including typ_dataTypes.xsd.

• typ_dataTypes.xsd – defines simplistic data types referenced by elements and attributes in WITSML data object and component schemas. Some of these types are included from the following special data type files.
• typ_catalog.xsd – defines the data types referenced by elements and attributes in WITSML data object and component schemas that are restricted content.  For elements restricted by content, the valid (enumerated) values are defined in this schema.
• typ_measureType.xsd – defines the subset of POSC measure types that are used in this specification. These types represent a numeric quantity with a unit of measure (uom) attribute. The allowed units of measure are controlled by types in file typ_quantityClass.xsd (see below).
• typ_quantityClass.xsd – defines the enumerated POSC unit of measure acronyms for each measure type.
• typ_baseType.xsd – defines the lowest level types. These are the types from which all other types are derived.  They allow the underlying behavior of types to be controlled in one place. For example, all types are constrained to not allow an empty value and strings are constrained to not allow a blank value.

File typ_catalog.xsd file contains enumerations that are considered to be relatively static and should not require frequent changes. However for some data the list of recognized values may change relatively frequently. For this type of data the values are enumerated in file enumValues.xml.

The unit of measure conversion information is defined in file witsmlUnitDict.xml. Abbreviations used within the WITSML schemas are documented here.

Data object schema design:

Since all XML documents can only have one root level element and there are situations where it is necessary to send multiple occurrences of a data object in a single XML document (e.g.; multiple wellbores in a well), a pluralized version of the data object name was established as the schema root element. That is, the object name followed by an "S" (e.g.; wells, wellbores, etc.).  In some cases, this leads to incorrect pluralization (e.g., trajectorys), but is required to order to meet the requirements of the WITSML API which generates root tag names based on the data object name. One component schema is included in all plural data object schemas:

• cs_documentInfo.xsd – Defines information that is relevant to a specific document such as when the document was created and who was responsible for creating the document.

The unique identifiers (uid) for data objects are always defined as attributes at the singular data object name level.

Naming convention in schemas:

A WITSML type can be one of four kinds; a definition only with possibly a restricted size specified, a definition with enumerated values that are permitted, a reference to a component schema and a reference to a element group schema. While not really a type, the element group schemas allow the same elements to be used in multiple different contexts. In order, to help identify which type is being referenced, the following naming convention is used.

• Type definition only - starts with lowercase, each new word begins with uppercase
  <xsd:element name="mdKickoff" type="measuredDepthCoord" minOccurs="0"/>

• Type definition with enumerated values – starts with uppercase and each new word begins with uppercase
  <xsd:element name="shape" type="WellboreShape" minOccurs="0"/>

• Reference to a component schema can be identified by the a "cs_" prefix.
  <xsd:element name="customData" type="cs_customData" minOccurs="0" maxOccurs="1"/>

• Reference to an element group schema can be identified by the a "grp_" prefix.
  <xsd:group ref="grp_well" minOccurs="0" maxOccurs="1'/>

Wells and Wellbores

WITSML has adopted the following definitions:

• borehole - A hole excavated in the Earth as a result of drilling or boring operations. The borehole may represent the hole of an entire wellbore (when no sidetracks are present), or a sidetrack extension. A borehole extends from an originating point (the surface location for the initial borehole or kickoff point for sidetracks) to a terminating (bottomhole) point.
• sidetrack – A borehole that originates in another borehole as opposed to originating at the surface.
• wellbore - A unique, oriented path from the bottom of a drilled borehole to the surface of the Earth. The path must not overlap or cross itself.
• well - A unique surface location from which wellbores are drilled into the Earth for the purpose of either (1) finding or producing underground resources; or (2) providing services related to the production of underground resources.

The definition of wellbore is intended to allow it to represent one and only one sidetrack or initial borehole. This assumes that only one sidetrack can have a particular bottomhole point. The wellbore may partially or completely overlap other sidetracks but it would not represent them.

For data bases that only contain wells, the name of the well generally contains knowledge of a specific sidetrack that is represented by that well. Information which is common to all sidetracks must be copied to each sidetrack well. Information from other sidetracks may also be redundantly copied to the sidetrack well. That is, the sidetrack well generally represents information from bottomhole to surface. In the WITSML view, the common data maps to a well and the sidetrack information maps to a wellbore. Data from other sidetracks may or may not be redundantly copied to a wellbore. Information about a borehole maps to a wellbore when that information is located using measured depths from the surface.

WITSML Schemas, XML Documents, and Stylesheets:

The WITSML standard includes the following data object schemas, component schemas and element group schemas:

WITSML Composite schema

bhaRun data object

cementJob data object

convCore data object

dtsInstalledSystem data object

Click here for an overview of Distributed Temperature Survey.

dtsMeasurement data object

Click here for an overview of Distributed Temperature Survey.

fluidsReport data object

formationMarker data object

log data object

message data object

mudLog data object

opsReport data object

realtime data object

rig data object

risk data object

sidewallCore data object

surveyProgram data object

target data object

trajectory data object

trajectoryStation data object

tubular data object

wbGeometry data object

well data object

wellbore data object

wellLog data object

Copyright(c) 2003-2006 Petrotechnical Open Standards Consortium, Inc. (POSC) All rights reserved.
POSC® and the POSC logo® are registered trademarks and WITSML™ and the WITSML logo™ are trademarks of POSC