WITSML Daily Drilling Report Schema

DRAFT

25 August 2006.

Preface

This material has been crafted to be compatible with the WITSML v1.3.1 specification. All schema files and this documentation can be downloaded here (530 KB zip).

Further information requests and technical feedback may be addressed to POSC.

Contents

• Daily Drilling Report
• WITSML Introduction
• WITSML Data Object Schema Design
• WITSML Naming Convention in Schemas
• Schemas
• dailyDrillingReport data object
• NPD Schema Profile

Daily Drilling Report

This schema is being targed as a replacement for the WITSML v1.3.1 Operations Report Schema. The Norwegian Petroleum Directorate (NPD) developed a content specification in collaboration with companies that operate in the Norwegian sector. That content specification was then merged with the existing WITSML operations report with the NPD content organization taking precedence.

NPD Schema Profile

For regulatory reports in the Norwegian sector, the Norwegian Petroleum Directorate has specified a more constrained view of the above daily drilling report.

• It has deleted some optional elements (e.g., some of the retained opsReport elements).
• It has made some optional elements mandatory.
• It has constrained the occurences of some elements (e.g., from unbounded to one).
• It has constrained some types to have a single allowed unit of measure (e.g., all depths in meters).
• It has deleted uid and uidRef attributes.

See file WITSML_drillReport_content_profile.xls to see which elements within the product volume schema have been flagged for "delete" status, a new (more constrained) type, a new minOccurs or a new maxOccurs. The resultant schema file can be viewed below in the schema section. It contains all types relevant for the profiled schema. As a result of deleting elements, some types are no longer needed which resulted in them also being deleted.

WITSML 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. These PRODML schemas are crafted to be conformant to the design characteristics of WITSML version 1.3.1. XML schemas are used to define the content of an XML document. The WITSML standard consists of two specifications which are versioned independently: Data Schema and Application Program Interface (API). This section provides an overview of the Data Schema design. 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 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 – 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.

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

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

WITSML 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'/>

Schemas:

This release includes the following data object schemas, component schemas and element group schemas.

drillReport data object

NPD Profiled drillReport data object

Copyright(c) 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