Witsml/> Core Application Program Interface Version 1


Terminology and Basic Concepts



Download 0.54 Mb.
Page2/21
Date31.07.2017
Size0.54 Mb.
#24987
1   2   3   4   5   6   7   8   9   ...   21

3 Terminology and Basic Concepts

3.1[WITSML] Object or Data Object


A WITSML data object is a logical organization and grouping of the data items associated with the major components and operations involved in drilling a well. For example, a group known as the rig “data object” would contain the data items related to the rig, such as its owner, type and manufacturer.

► A WITSML data object is not, however, a formal programming object


(with methods, properties, events, etc).

These data objects can be organized into a single hierarchical “tree”, with the well object at the top of the tree. The well object is the parent of one or more wellbore objects, a wellbore object has one or more children, and so on.



► When being exchanged between systems, each of the logical objects


is represented as a
physical XML document.
That is, all the data items in one wellbore object are transported as one XML document, which is simply a text file. In order to transport the complete tree shown above, five XML documents are required. The objects can be logically thought of as being in one tree, but they are physically represented as five separate documents.
Since each object carries with it its own identifier and the identifier(s) of its’ parent, grand-parent, etc, the tree can be reconstructed from the individual documents.

3.2Unique Identifiers (UIDs)


Every WITSML data object has within it an identifier, and the identifier(s) of its ancestry. For instance, a Mud Log (mudLog) object has an identifier of itself, and the identifiers of its parent (wellbore) object and its grandparent (well) object.

These identifiers are known as "unique identifiers" or UIDs. The Mud Log’s own identifier is its uid attribute, its parent wellbore is its uidWellbore attribute and its grandparent is its uidWell attribute.

The uid of each singular object should be made globally unique by generating uids according to uuid algorightm of rfc 4122 (http://www.faqs.org/rfcs/rfc4122.html).

Because these system oriented-unique identifiers might contain internal keys or other not-easily-readable values, elements have been defined to carry more "human readable" names of an object and its parentage, such as nameWell, nameWellbore, name, etc.

Each repeatable element (i.e., has maxOccurs greater than 1) that needs to be individually queried by the server (e.g., update a single node) must have a uid attribute. If an element has a uid attribute then all repeatable parent elements must also have a uid attribute. A non-repeatable element should not have a uid attribute. For the purposes of this discussion, a foreign key to a non-parent node is not considered to be a uid value. The only purpose of uid values is to insure uniqueness of nodes in a server. Best practice should not assume any semantic content of a uid value.

Each individual child uid value is only required to be unique within the context of its nearest repeatable parent node. The unique key for any node is the combination of all uid values in the hierarchy down to and including that node. Each uid value may actually be unique within a broader context but best practice should not assume a broader context.

Some WITSML objects that utilize the plural convention may combine to represent one hierarchical tree (e.g., well/wellbore/...). For objects that represent a common hierarchy, the repeatable parent node may exist in another object that is referenced using a parent key. For example, the wellbore object would reference a well uid. Since the unique key for a node must necessarily include the unique key for its nearest repeatable parent node, the unique key of a child object of a wellbore object would include the wellbore key (i.e., a well uid value and a wellbore uid value) in addition to its own uid value.

Similarly, any "natural" human recognizable identifiers (e.g., name, index) for a node should be populated with values that identify the node within the context of the nearest repeatable parent node. For objects that represent a common hierarchy, the name pointer to parent another object is part of the uniqueness of that object. The possibly-unique natural key for a node is the combination of all natural identifiers in the hierarchy down to and including that node. While natural keys are not required to be unique within the context of a server, every effort should be made to insure their uniqueness in order to eliminate ambiguity. Where the natural keys are not unique then human inspection is required to determine if the nodes represent the same thing (and they should be combined) or if they represent different things (and their identity should be changed).


3.3Representation versus Transport


WITSML data objects being exchanged between systems are always represented as XML documents. The WITSML XML Schemas define the format of these objects when they are represented as XML documents.

Since XML documents are simply text files, they can be transported by various means, such as email or other file transfer method. A WITSML data object could even be in the form of a printed or Faxed document.

The WITSML API described in this document specifies a standardized way of electronically transporting WITSML data objects between systems using the HTTP/S-based protocols. However, it is acceptable for companies to agree to send and receive WITSML data streams without the use of the WITSML API.


We will use the term "HTTP" in this document to specify "Hypertext Transport Protocol (un-encrypted)".

We will use the term "HTTPS" to specify "Hypertext Transport Protocol over Secure Sockets Layer (encrypted)"

We will use the term "HTTP/S" when generically referring to both HTTP and HTTPS.





Download 0.54 Mb.

Share with your friends:
1   2   3   4   5   6   7   8   9   ...   21




The database is protected by copyright ©ininet.org 2024
send message

    Main page