1. Technical Team WITSML SIG Dubai - November 2008 John Shields / Gary Masters

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

3. WITSML Issues List

4. Dubai 2008 Topics Focus on Automation and Interoperability Standard Queries New Query API Schema and Versioning WITS Data

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

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

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

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

9. 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?

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

11. Schema Extension Add extension element to selected container objects e.g. Add extension element to –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 to define extension data

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

13. Technical Team If you want to contribute – join the SIG!

14. Thank you