Technical Team

WITSML SIGDubai - November 2008John Shields / Gary Masters

WITSML Technical Team

• Representatives mainly from service companies

• Energistics (Gary) keeps a global issue list accessible via private area on Energistics web site

• Monthly conference calls• Twice a year face-to-face

meetings at WITSML SIG working meetings

WITSML Issues List

Dubai 2008 Topics

Focus on Automation and Interoperability

• Standard Queries• New Query API• Schema and Versioning• WITS Data

Query Templates

Issues• WITSML query templates are very flexible but allow

infinite variations on the types of queries that can be made

• Makes it very difficult to implement WITSML servers with predictable behavior or prerformance

• Lots of special cases for queries on specific types of objects

• Queries need to be independent of underlying server technology. Cannot use SQL or XQuery

Query Templates

• Review test queries from interoperability team• Well navigation queries, return name and uid list

– Get name/uid for all wells in server– Wells by country, field, operator, region, block, status– Wild card (*)– Wells by coordinate system and lat, long

• General Queries for all objects– Get name/uid for all objects of a type– Get complete object from a uid– Get name/uid and dTimLastChanged for a specified object type > dTimLastChanged

• Wellbore queries– Get all well/wellbore name/uid information– Get all wellbore name/uid in a well

• Growing Objects– Get summary header data for all objects of a specified type in a wellbore

• For log/wellLog this would not include logCurveInfo– Get range of data for a specific object uid on depth– Get range of data for a specific object uid on time

• Log Queries– Get data for a specified set of curves in a log– Get logs containing specified classWitsml curves

Queries for range of data

• For growing objects, client must determine the index units that the server is using then query for a range of data in those units– Client queries log/mudlog/trajectory header to determine

start/end index and units– Client requests range of data in the same units as the server

specifies– Discussion on server handling of data range queries

• Server should interpret the units in a range query and return data in the specified range

Query Interfaces

• Short Term: Simplify and standardize current template queries by defining a set of WITSML ‘standard’ queries that are incorpotrated into the test and certification process for WITSML clients and servers

• Longer Term: Develop a new API or APIs with more specific queries based on the standard templates

Versioning & Namespaces

Issues• When a schema version changes, code generation

tools (typically in .NET or Java) create a new set of code classes that are not compatible with classes from the previous version

• XQuery does not work across multiple schema versions. Need to run separate queries on each version then combine results

• How to extend existing WITSML schemas without breaking existing program code?

Versioning & Namespaces

• XML Schema namespace should not change for minor versions or for compatible versions e.g. 1.3.1 to 1.4

• Suggest removing version section from namespace in the next major version. We already have a “version” attribute

<logs xmlns="http://www.witsml.org/schemas/140" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.witsml.org/schemas/140 ../XSD_Schemas/obj_log.xsd" version="1.4.0.0">

• Use different namespaces for WITSML and PRODML (and common objects)?

– Allows WITSML and PRODML to progress in parallel• Can we change this for WITSML 1.4?

– Use generic namespace as xmlns="http://www.witsml.org/schemas/1– Implement extensibility mechanism

• Add <xsd:any> to commonData and customData• Add name/value pair extension element to all recurring data structures

– Re-instate and deprecate deleted elements in 1.4.0

Schema Extension

• Add extension element to selected container objects e.g. <logCurveInfo>

• Add extension element to <commonData>– Extension element has

• Kind (defined in enumValues.xml [or local])• Data type (string, double, etc.)• Value• Uom (for numeric types)

• Extension type defined in enumValues.xml for global approved extensions. Private (local) extensions may also be allowed

• Alternatively use <xsd:any> to define extension data

WITS Data

Issues• Provide an easy transition from WITS to WITSML• Preserve the efficiency of WITS data stream

• Translate to WITSML Log object – enables persistence at server

• Need to evaluate more efficient syntax for data transfer

Technical Team

If you want to contribute – join the SIG!

Thank you