Saturday, March 11, 2006

Woefully Underspecified

Gary Masters of POSC circulated an email today, beginning "I was trying to create an update template and I realized that the behavior is woefully underspecified."

The first problem is the WITSML group has attempted to create a query and update language, but has done that in an ad hoc, unrigorous manner.

The second problem is that no amount of tightening up the query/update template spec is going to make WITSML widely interoperable. Just look at the rest of Gary's email, with its mind-numbing eight point plan to rationalize the update template. Forget the servers -- this is about three orders of magnitude too much complexity for clients to implement. Hell, half the WITSML client programs out there are still hung up on "Get all the logs for a well."

If you want interoperabilty, and I mean the kind of interop so easy that mud logging shops with a one man programming staff can do it, then we should focus on getting/replacing/deleting documents -- not all this complex query and update behavior crudding up WITSML.

Most WITSML document types -- the non-growing ones, like well, wellbore, rig -- are so small, all you need are HTTP GET, PUT, and DELETE. Want to update a document? Download it with GET, modify it, and replace the whole darn thing with PUT.

Looking for a WITSML object? Start at the top: GET a list of wells, follow hyperlinks to a list of wellbores, and then follow hyperlinks to a list of objects in the wellbore, and locate the object you want. Every WITSML client program displays that tree in the left hand pane of a window! But to build that tree they make an awkward series of WITSML queries. The query template syntax is also woefully underspecified, but no matter, because 99% of all WITSML queries are "Find me all the [logs, trajectories, or whatever] in this wellbore."

To make a document oriented strategy work perfectly, we need to address the growing objects: logs, mud logs, well logs, trajectories. A time log of surface measurements at 1 s intervals can get unmanageable quickly. It's impractical to GET a whole time log, add a line of data to it, and PUT it back.

For appending data the best approach is to permit POSTing data to the object. This is what Wellstorm does. Want to add a element to a log? Just POST it to the log's URL. You can also POST a realtime to a log and Wellstorm does the right thing. Apply the same pattern to or any other repeating element in a growing object.

What about retrieving ranges of data? Well, you don't need it. Of all the WITSML objects, only log objects typically grow so very large they need some management over the life of the well. Solution? Make smaller logs. Depth logs aren't a problem, but for time logs: Close off the log and start a new one in that wellbore each day. There are 86,400 seconds in a day. That's how many lines you'll get in the largest log file, in a day. That's a manageable size for downloading as a whole. Let client programs worry about selecting the portions of interest.

Wellstorm already implements all of this. Naturally we expose the standardized and "woefully underspecified" WITSML interfaces. But we also publish the straight HTTP interfaces I've described here. When doing customer integrations, we use the HTTP interfaces. And we encourage all vendors to expose simple HTTP interfaces as we have. A little bit of standardization would help, but the spec for interchanging data this way would be fewer than ten pages.

The benefit would be that we will tremendously lower the barriers to exchanging WITSML data.

0 Comments:

Post a Comment

<< Home