Completions Data Schema Overview

Version 1.0

This document contains the following sections:

• Introduction
• Data object schema design
• Naming convention in schemas
• Completions Data Objects
• Schema Variants
• Completions Schemas, XML Documents, and Stylesheets

Version 1.0 represents a new object.

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 Completion data-object is an XML specification for describing a well completion throughout its whole history. With a standardized description, the completion data can be accurately, reliably, and consistently exchanged between the many software applications used to plan, manage, and record work on a completion over the life of a well.

The Completion data-object is officially part of the Energistics WITSML data exchange specification (which defines wells) but has been designed to also work with Energistics PRODML (production) and RESQML (earth modeling/reservoir) data exchange specifications. Note that specific production and reservoir domain requirements have not been addressed in this first release, but are expected to be added in later releases.

Component schemas are XML schemas, but these schemas do not represent complete data objects and do not contain global elements. A component schema may be used 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_dataTypesWitsml.xsd (or typ_dataTypes.xsd). If a component schema includes another component schema then it will be indirectly including typ_dataTypesWitsml.xsd.

• typ_dataTypes.xsd - defines simplistic data types referenced by elements and attributes in Completions 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 Completions data object and component schemas that are restricted content. For elements restricted by content, the valid (enumerated) values are defined in this schema.
• typ_catalogCompletion.xsd - defines the data types referenced by elements and attributes that are unique in the Completions 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_measureTypeCompletion.xsd - defines the subset of POSC measure types that are unique 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_quantityClassCompletion.xsd (see below).
• typ_quantityClass.xsd - defines the enumerated POSC unit of measure acronyms for each measure type.
• typ_quantityClassCompletion.xsd - defines the enumerated POSC unit of measure acronyms for each measure type that are unique in this specification.
• 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 and a non-normative spreadsheet of this content is in file enumValues_spreadsheet.xls.

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 Completions 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 Completions 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 or a reference to an 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 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

Completions 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.

Completions Data Objects:

The Completions object includes the following data objects:

downholeComponent

wellCMLedger

wellboreCompletion

wellCompletion

Schema Variants

In addition to the normative schemas defined here, Completions generates schema variant for use in the API. The following variants are mechanically derived from the normative schemas.

• The read schemas are a copy of the normative schema except that all elements and attributes are optional. A read schema is intended for validating a response from WMLS_GetFromStore.
• The write schemas are a copy of the normative schema except that the optionality on the unique identifier attributes may have changed. See the API document for a summary of the unique identifier requirements. A write schema is intended for validating the input to WMLS_AddToStore.
• The update schemas are a copy of the normative schema with all elements and attributes optional except that all unique identifier attributes are required and uom attributes are required. An update schema is intended for validating the input to WMLS_UpdateInStore.

Completions Schemas, XML Documents, and Stylesheets:

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

XMLs can be viewed in Internet Explorer 9 by changing Compatibility View Settings.

downholeComponent data object

wellCMLedger data object

wellCompletion data object

wellboreCompletion data object