In the last years it has become a common conventionality to use a dive computer for scuba diving. Many manufacturers serve the market today. Most scuba divers have a dive computer and use it to plan, and do their dives. Because the prices are dropping divers begin to own two dive computers, one as a reserve. Due to this common use many beginners don't (know how to) use decompression tables any more. Though this evolution isn't desirable — dive computers have errors, as every computer system —, it cannot be stopped, or even hold up, the advantages are too great in the practical use.
Besides the above mentioned problem, the broad distribution of dive computers is advantageous, at all. It makes the planning of dives easy(ier), and today decompression calculations including Nitrox as breathing gas are standard. Additionally, many dive computer models display the tank pressure, and perform an oxygen toxicity calculation as well. Some advanced dive computers include Trimix ability, and support the change of different breathing gases in the decompression calculation, too.
Today, another feature is found in every dive computer: a profile data memory. In certain time intervals the dive computer stores the current depth, and — may be — water temperature, as well as warnings. Although this seems to be a "nice goodie" at first glance, many applications evolved from this — hopefully, to make scuba diving safer in the future (at least some).
Evidently, one application of the profile data memory is the implementation of electronic logbooks. Here a (Mac, PC, PDA etc.)program is used to download the relevant data from the dive computer for storing them in a database. Afterwards, the user can add additional information to his logbook, for example buddies, special observations, or equipment used etc.
Many programs for this purpose are available today, which serve a broad range of platforms (from PDA up to desktop computers). Online versions can be found in the World Wide Web, too (e.g. Itzchak Rehberg, phpDiveLog, 2004, http://www.qumran.org/homes/izzy/software/pdl/demo.php). This use of the profile data memory of dive computers is desirable, naturally.
However, another application is more interesting, and much more important. In modern decompression research a multitude of statistical data is necessary to verify decompression models in use, or to develop new decompression algorithms. Divers Alert Network (DAN) realized this some time ago and developed their medical format DL7 (Petar J. Denoble, DL7 Standard, DAN - Project Dive Exploration, 1998, http://www.diversalertnetwork.org/research/projects/pde/). It encompasses not only the profile data, but also a lot of medical data, too. This format is background for many "Send data to DAN" functions of several electronic logbooks.
All programs of this kind have an important disadvantage: data exchange between different programs is not possible, or only with great difficulties, at least. This means, using a program made by manyfacturer X, it is (very) difficult to import the data into a program made by manyfacturer Y. In other words, the software available today is mostly an "island solution" subject to needless restrictions. It is difficult to conduct his dive data over long periods of time. Particularly, large collections of dive data, for statistical evaluations e.g., are to be managed only with great efforts. Due to the construction of DL7, which obviously was developed for medical applications and whose data format isn't any longer in accordance with modern informatics, it is not suitable for this purpose.
A possible workaround would be to help oneself with converter programs which translate a format in another one. But this approach has two disadvantages. One is, that the data formats used by the different manufacturers are normally not documented and therefore not available to developers of converter programs. Another disadvantage is that a great number of converter programs must to written. Assume there are n different electronical logbooks to be supported. To import each data format in every program we need n * (n-1) different converters. This means, if we have ten different manufacturers, we need 90 different converters! Obviously, this approach isn't useful.
Many programs support import and export of so-called "comma separated text files" (CSV files). But there doesn't exist any standard, and the exported fields and their order vary between different programs. Another great disadvantage is the fact that there is practically no possibility to store a logbook entry consisting of profile data, text data (observations, descriptions etc.) in a CSV file. Some programs omit the profile data in CSV files, other ones store these information in separate files per dive. It's not possible to uniquely assign the meaning of the individual data stored in the file. This makes the import of the data into another program more difficult.
Another approach is much more encouraging. For this a universal format for the interchanging of data is used. In our above example now only ten converters, or converter applications respectively, for this unversal exchange format have to be written to support all combinations of electronic logbooks, and medical applications. If a freely available library for read, and write operations for this universal format is provided, many manufacturers are expected to support this format. The integration takes place with a minimum developmental effort and offers a real added value of the program. A possible implementation of this approach is the Universal Dive Data Format, or short UDDF.
Developing such a universal data exchange format like UDDF the thing to do is to use methods of modern informatics. A good choice is a kind of XML, the "Extensible Markup Language" (WorldWideWeb Consortium W3C, Extensible Markup Language (XML), 1996 – 2003, http://www.w3.org/XML/) which was developed for the purpose of universal interchangeability. Today it is used in many application programs - from text processing software up to editorial systems, and in the World Wide Web. For this reason there exists a vast range of tools, program libraries, and literature about XML. Therefore UDDF was embedded in the XML world. The consequences for software developers are easy usability what hopefully will lead to a broad availability and usefullness for users. Simultaneously, UDDF is a text based format which can be read by man — the guarantee that dive data can be processed even in twenty years and later. That this concept is working demonstrate the predecessor UDCF (Steffen Reith, Kai Schröder, UDCF - Universal Dive Computer Format, http://www.streit.cc/dive/udcf_doc_ger.html), which is used in some applications (for example in Steffen Reith's EONTools, 2002, http://www.streit.cc/dive/index.html, and in Kai Schröder's Dive-Simulation Program Tausim v0.99, http://www.achim-und-kai.de/kai/tausim/tausim.html), and the AquaDiveLog program by Stephan Veigl, http://www.aquadivelog.org, which already uses a first version of UDDF.