Roger's earlier article entitled The Importance of AGS Key Fields for Sample Data explained some of the problems involved with transferring sample data in AGS 3.1.

This article will define exactly what is meant by a Sample and a Specimen, how they differ in meaning within DIGGSML and how they relate to each other. This article will explain some of the methods of transferring Sample and Specimen data that were considered for DIGGSML and detail the method finally chosen and the reasons behind its choice.

I will also include some best practices for companies implementing DIGGSML in the real world to help make the use of DIGGSML as productive as possible.

Key Fields play a vital part in the structure of AGS 3.x data. This article shows some of the problems commonly encountered when transferring data in the AGS SAMP and test tables and gives guidence on how to minimise and eliminate these problems.

Keep checking back for the next in this series on sample referencing as we explain how DIGGSML solves these problems soon.

Yesterday I posted a suggestion on how I was thinking of implementing monitoring in DIGGSML, after some consultation we have decided to make some changes! This is a new proposal (which supercedes the previous one), with a much more generic structure. Allowing DIGGSML to cope with monitoring devices and instrumentation that we don't currently use (indeed may not even be manufactured yet!) is very important as it would be impractical to update the framework every time a new instrument was marketed.

This article details a new implementation of Monitoring, allowing DIGGSML to transfer monitoring data for any number of parameters, with any number of readings, for all pre-exisiting instruments and any that may arise in the future.

Here's one proposal for implementing Monitoring In DIGGSML, using a SamplingPoint object, it sits alongside the Hole and FoundationGroup objects inside a Project. This post will explain the structuring of the proposed SamplingPoint object, it's contained Instruments (both single and multiple reading), their associated readings and how to record one or many readings from the same instrument.

Please note that the information contained in this article is now superceded by the article located Here

DIGGSML brings a great benefit with it, it actually validates the data in the file, knowing wether a property should be a length, mass, pressure or a great number of other measurements, this article shows how DIGGSML enforces valid data by only allowing a file to validate once it contains all the information required to represent a property.

Before Chris and I start to dive in and explain how DIGGS fits together I thought it would be useful to clarify the terms that we are going to use when describing the structure of DIGGS.

I've been working with XML for a while now and I thought I'd share some of my experiences. This document will detail some best working practices relating to XML and the tools I use to help me work with it.