WITSML Data Schema Overview

Regulatory Reporting

Version 1.0 Release Candidate

This document contains the following sections:

• Introduction
• Data object schema design
• Naming convention in schemas
• Wells and Wellbores
• Batch Schema
• Example XML documents, and Stylesheets
• WITSML Schemas

Preface

This material was developed through cooperation between Energistics, the Ground Water Protection Council (GWPC) and the US Bureau of Land Management (BLM). The work was partly funded by a grant from the US Department of Energy (DOE). Its purpose was to create a batch data exchange standard to facilitate the reduction of the cost of information exchange between the petroleum and mining industries and regulatory agencies over the Internet. The resulting specifications are compatible with the relational tables from the GWPC's Risk Based Data Management System (RBDMS). The GWPC is engaged in a broader initiative related to e-Commerce which is beginning a staged implementation of these specifications in several US states.

US regulators have broadly diverse requirements that were already reflected in RBDMS and care has been taken to remain generic and suitable for international use. Input from other regulators is solicited in order to further broaden the base of these specifications.

Further information requests and technical feedback may be addressed to Gary Masters or Alan Doniger at the Energistics offices in Houston.

This overview is non-normative and is not part of the standard. This material has been modified to be consistent with the current published WITSML Drilling Standards (v1.3.1.1). The Energistics Special Interest Group (SIG) that addresses these specifications is the eRegulatory SIG. Requests for additions or changes should refer to this SIG.

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. Newly added types are in file variants with "_NEW" as part of the name.

• typ_dataTypes.xsd and typ_dataTypes_NEW.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 and typ_catalog_NEW.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 and typ_measureType_NEW.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 and typ_quantityClass_NEW.xsd – defines the enumerated POSC unit of measure acronyms for each measure type.
• typ_baseType.xsd and typ_baseType_NEW.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.

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

Batch Schema

XML Documents, and Stylesheets

US Regulatory Examples

WITSML Schemas

A single file variation of the normative schema files are contained in file batch_regReporting.xsd. All unused types have been eliminated from this file.

batch_regReporting data object

wellNotice data object

Copyright(c) 2003-2006 Energistics. All rights reserved.
POSC® and the POSC logo® are registered trademarks and WITSML™ and the WITSML logo™ are trademarks of Energistics