APPENDIX A - Example Data Object Schema

9 APPENDIX A - Example Data Object Schema

1. 
   The root elements are a plural form of the first child element that is formed by adding an “s” to the singular child element. The singular child will be called an “object” within the context of this specification.
   
2. 
   The object has mandatory uid attributes. In this example, they are named “uid”.
   
3. 
   An object may have foreign uid keys to a “parent” object. In this example, the attributes are named by suffixing “uid” with the parent object name. For example, the parent object of welbore is well. The foreign key from wellbore to well is uidWell. A server may or may not take advantage of this for something like referential integrity.
   
4. 
   Recurring nodes that are intended to be updatable via WMLS_UpdateInStore must have a uid attribute. An update of a recurring element that does not have a uid attribute will result in all existing instances of the element being replaced.
   

The mudLog object represents a randomly growing object. It has two recurring child elements that both contain “index” values (i.e., mdTop and mdBot). The mudLog contains corresponding “index” values (i.e., startMd and endMd) that represent the range of the child index values in that mudLog.

The trajectory object is similar to the mudLog object except that its recurring child element represents a point rather than an interval. The relevant indexes are mdMx, mdMn and md.

The log object represents a systematically growing “table” where the data is added as “the next row”. The table has an index column and index range values (i.e., startIndex, endIndex, startDateTimeIndex and endDateTimeIndex) for the overall table (in logHeader) and for individual columns of the table (in logCurveInfo).

The realtime object represents a transient stream of data. There will be one header for each wellbore.

The actual form of these objects in a data model is not critical to the behavior described in this specification. It is the servers responsibility to adjust to variations in the schemas and to support the relevant behavior. Inherent to this behavior is that the server must understand underlying concepts such as units of measure, data types, index columns, etc.