Units, Data Types and Validation

One of the great benefits of DIGGSML is that it validates the data in the file, only allowing the file to validate when it "makes sense".
Take the example of the totalSwell property of a CBR test, DIGGSML knows that this is measured as a length, rather than pressure, mass etc. Data is no-longer just a string, number or date/time, DIGGSML knows the difference between a length and a pressure, and therefore how that type of data must be represented.

Units of Measurement


Here's an example of the totalSwell element empty.
Example 1:
<CBR> 
    <totalSwell></totalSwell>
</CBR>

This is invalid for many reasons, firstly, the totalSwell element doesn't contain a value, and a number is not valid unless it has a value!
So add a value:
Example 2:
<CBR>
    <totalSwell>5</totalSwell>
</CBR>

However, this is still invalid, totalSwell is defined as a length, and a length is not valid unless we know what it's measured in, the units of measurement in use are defined by the uom attribute. Here we can try and fool it by adding a "dummy" unit of measure:
Example 3:
<CBR>
    <totalSwell uom="">5</totalSwell>
</CBR>

This is still not valid, since DIGGSML has a pre-defined (and user definable) list of units that are valid to be applied to a list, and "" (nothing) is not one of them!

DIGGSML also has these unit lists for other types, mass, pressure etc, but it knows which units are related to which data types, so the following is still not valid, despite the fact that "kg" is a valid unit elsewhere.
Example 4:

<CBR>
    <totalSwell uom="kg">5</totalSwell>
</CBR>

The only way to make our sample valid is to add a proper length unit of measurement, this can be m (metres), mm (millimeters), in (inches), ft (feet) or any of 50-something others. Here we'll add it as "mm".
Example 5:
<CBR>
    <totalSwell uom="mm">5</totalSwell>
</CBR>

Now this IS valid DIGGSML, it knows that mm is a valid unit of length and that this is acceptable.

Much of this data type and units work was taken from the POSC (now Energistics) group's work on WITSML, which defines many of the data types used in DIGGSML.

Conversion


As part of the work in WITSML POSC also generated a file that defines how the units "fit together", showing that 1 in = 25.4mm and so on here's the example for inch, showing how to convert inches to metres...
Example 6:
<UnitOfMeasure id="in" annotation="in">
    <Name>inch</Name>
    <!-- removed list of uses -->
    <DimensionalClass>L</DimensionalClass>
    <SameUnit uom="in" namingSystem="RP66"/>
    <CatalogName>POSC</CatalogName>
    <CatalogSymbol isExplicit="true">in</CatalogSymbol>
    <ConversionToBaseUnit baseUnit="m">
        <Factor>0.0254</Factor>
    </ConversionToBaseUnit>
</UnitOfMeasure>

It's possible that applications supporting DIGGSML can use this "mapping" to allow the user to enter data in any format, and automatically display it in any other format.

This conversion will be covered in more detail at a later date.

Summary


DIGGSML is adding power to the format by enforcing the integrity of the data, that data can be in any unit-system and there is already a mechanism for converting between them.

DIGGSML simply doesn't allow the user to have data that isn't valid, it's easier for developers, and safer for users.