WITSML v1.4.1.1 Data Schema Overview with Raster v1.0

This document contains the following sections:

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

Version 1.4.1.1 represents an enhancement to version 1.4.1. Data Schema changes between versions 1.4.1 and 1.4.1.1 are summarized in the Change Summary. The changes are itemized in the change detail file.

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

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 Data Objects:

The WITSML standard declares the following data objects as growing objects: log, wellLog, trajectory, mudLog. These objects commonly grow slowly with time as the wellbore is drilled. Special query behavior has been included in the API specification for growing objects and special query elements are included in these objects.

The WITSML standard includes the following data objects:

attachment

The attachment object is used to provide a central location for finding a digital attachment that is associated with another WITSML well related object. The attachment is captured in a base 64 binary type.

bhaRun

The bhaRun object is used to capture information about one run of the drillstring into and out of the hole. The drillstring configuration is described in the tubular object. That is, one configuration may be used for many runs. This object is uniquely identified within the context of one wellbore object.

cementJob

The cementJob object is used to capture information about cementing operations which are undertaken to seal the annulus after a casing string has been run, to seal a lost circulation zone or to set a plug to support directional drilling operations or seal a well so that it may be abandoned. This object is uniquely identified within the context of one wellbore object.

changeLog

The changeLog object is used to provide a central location for knowledge of changes in the other objects. This object only makes sense within the context of a WITSML server because there is no domain data in the object.

convCore

The convCore object is used to capture information about a conventional core. This includes a description of the geology and lithology over the interval. See also sidewallCore. This object is uniquely identified within the context of one wellbore object.

coordinateReferenceSystem

The coordinateReferenceSystem object is used to define the details about a Coordinate Reference System (CRS) using GML version 3.2.1 schemas as defined at https://schemas.opengis.net/gml/3.2.1/. A best practice would be to reference a well known CRS as defined by the EPSG (https://www.epsg.org/) rather than using the coordinateReferenceSystem object to define one from scratch.

depthRegImage

The depthRegImage object is used to define the details the Raster object.

drillReport

The drillReport object is used to capture a daily drilling report focused on reporting from the operator to partners or to a governmental agency. See the opsReport object for a similar report whose focus is service company to operator. This object is uniquely identified within the context of one wellbore object.

fluidsReport

The fluidsReport object is used to capture an analysis of the drilling mud. This object is uniquely identified within the context of one wellbore object.

formationMarker

The formationMarker object is used to capture information about a geologic formation that was encountered in a wellbore. This object is uniquely identified within the context of one wellbore object.

log

The log object is used to capture the curves on a well log. It was designed primarily for MWD logs and is constrained to capturing curves from a single pass. See wellLog for more complex logging situations. This object is uniquely identified within the context of one wellbore object.

message

The message object is used to provide a central location for informative time stamped information about another well related object. These messages can represent alarms, warnings, events, etc.

mudLog

The mudLog object is used to capture information in a mud log. This includes lithologic information derived from cuttings encountered on a shaker screen at a site. This object is uniquely identified within the context of one wellbore object.

objectGroup

The objectGroup object is used to capture explicit knowledge that multiple different object instances are related. The relationship generally relates to a common acquisition technique such as logging while drilling, wireline logging, well test, wireline formation test, etc.

opsReport

The opsReport object is used to capture a daily drilling report focused on reporting from the service company to the operator. See the drillReport for a similar object whose focus is operator to partner or to governmental agency. This object is uniquely identified within the context of one wellbore object.

rig

The rig object is used to capture information about a drilling rig used to drill a wellbore. This object is uniquely identified within the context of one wellbore object.

risk

The risk object is used to provide a central location for capturing risk information about other well related objects.

sidewallCore

The sidewallCore object is used to capture information about a core from the side of a borehole. See also convCore. This object is uniquely identified within the context of one wellbore object.

stimJob

The stimJob object is used to capture a post job summary report about a stimulation (fracture) job. This object is uniquely identified within the context of one wellbore object.

surveyProgram

The surveyProgram object is used to capture information about the nature, range and sequence of directional surveying tools run in a wellbore for the management of positional uncertainty. This object is uniquely identified within the context of one wellbore object.

target

The target object is used to capture information about intended targets of a trajectory survey. This object is uniquely identified within the context of one wellbore object.

toolErrorModel

The toolErrorModel object is used to define a surveying tool error model. This object is globally unique.

toolErrorTermSet

The toolErrorTermSet object is used to define a set of surveying tool error terms which may be utilized in a toolErrorModel. This object is globally unique.

trajectory

The trajectory object is used to capture information about a directional survey in a wellbore. It contains many trajectory stations to capture the information about individual survey points. This object is uniquely identified within the context of one wellbore object.

tubular

The tubular object is used to capture information about the configuration of a drill string. See the bhaRun object for information about a use of this configuration. This object is uniquely identified within the context of one wellbore object.

wbGeometry

The wbGeometry object is used to capture information about the configuration of the permanently installed components in a wellbore. It does not define the transient drilling strings (see the tubular object) or the hanging production components. This object is uniquely identified within the context of one wellbore object.

well

The well object is used to capture the general information about a well. This might sometimes be called a well header. All information which is the same for all wellbores (sidetracks) is contained in the well object.

wellbore

The wellbore object is used to capture the general information about a wellbore. This might sometimes be called a wellbore header. A wellbore represents the path from surface to a unique bottomhole. The wellbore object is uniquely identified within the context of one well object.

Schema Variants

In addition to the normative schemas defined here, WITSML 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.

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

attachment data object

bhaRun data object

cementJob data object

changeLog data object

convCore data object

coordinateReferenceSystem data object

depthRegImage data object

drillReport data object

fluidsReport data object

formationMarker data object

log data object

message data object

mudLog data object

objectGroup data object

opsReport data object

rig data object

risk data object

sidewallCore data object

stimJob data object

surveyProgram data object

target data object

toolErrorModel data object

toolErrorTermSet data object

trajectory data object

tubular data object

wbGeometry data object

well data object

wellbore data object

Copyright(c) 2003-2023 Energistics. All rights reserved.
WITSML™ and the WITSML logo™ are trademarks of Energistics and The Open Group.