WITSML and the Web

WITSML not "Document Oriented"

Some more refining of a subtle problem with WITSML. The 1.30 API tightens up the specifications of how servers handle update requests on growing objects like logs. Good! The server's responsibilities are a little clearer now.

The problem is that the server has responsibilities. The server has to understand what a log object is. If you append some <data> elements and only some curves are present, the server must fill in empty curves with the null value. Probably the server must also update the start and end indexes as another side effect (still never explicitly stated in the API).

Even if we someday exhaustively specify server responsibilities, these complex responsibilities are bound to be implemented differently by each company, and incorrectly in many cases. It's an interoperability nightmare.

Contrast that to a document oriented approach: a client would retrieve the data it needs, modify it as neccessary, and update the log object. No side effects: the client submits fully correct <data> elements, including nulls for the omitted curves; it may update the start and end indexes. In this scenario, the client's expectations are never disappointed! Any mistakes are the client's responsibility. A really good server would enforce integrity and prevent clients from making inconsistent changes. Yet a poorly implemented server that did not enforce that integrity would still work well with a well-behaved client. (And anyway, integrity requirements on one server may be quite different from those on another server; under document-oriented approach, it is fine for integrity constraints to be server specific).

In case you're wondering about efficiency: the document oriented approach doesn't mean you have to send complete log objects back and forth just to update. You can still use an update protocol as we do now. It just shifts responsibility for performing complex transformations on data, to the guy who wants to do them -- the client.

Document orientation is a shift in outlook that would make servers less complex to build, and more widely available.

posted by hughw @ 7:09 PM