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.
<CBR>
<totalSwell></totalSwell>
</CBR>
<CBR>
<totalSwell>5</totalSwell>
</CBR>
<CBR>
<totalSwell uom="">5</totalSwell>
</CBR>
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>
<CBR>
<totalSwell uom="mm">5</totalSwell>
</CBR>
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.
<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>
This conversion will be covered in more detail at a later date.
DIGGSML simply doesn't allow the user to have data that isn't valid, it's easier for developers, and safer for users.