Being able to create your own tag sets and rules allows a very flexible tool that can be used to mark-up every conceivable type of text-based data, and do so in nearly any language. This is one of the primary differences between XML and database technologies: the XML tag sets must conform themselves to common rules, which ensures that the information contained within an XML document can be understood and processed without recourse to a specific computer program or hardware platform.

Common and Conflicting Standards

XML is of course more than a simple annotation tool - it allows us to create data standards that embrace the diverse manner in which archaeology is recorded and practiced, without dictating the use of specific computer hardware or software. With XML we can now turn our attention away from the eternal debate on the relative merits of the PC and the Mac, and address instead, as a professional community, the quality of the information we are recording.

The success of an XML standard is best assured when it is the result of a well-considered process, created by a body representing the community it serves. In this light I am particularly optimistic about the future of MIDAS XML, the data standard for Cultural Heritage Management created by the Forum for Information Standards in Heritage (FISH) in the UK. MIDAS XML is a rule set that defines how information for 'monument inventories' is to be recorded and -- most importantly -- exchanged. MIDAS itself is in fact a mature data standard that pre-dates XML, first created by English Heritage but now employed throughout the entire UK and further abroad. The original MIDAS was the result of communal discussion and consensus, and MIDAS XML is designed explicitly to be extremely accommodating to the various ways in which the MIDAS standard has been implemented. Only XML can accommodate diverse working practices while at the same time standardizing how the data are recorded.

I do not believe that there will never be one unifying data schema for archaeology: the profession is too disparate, the data too diverse, and the discipline too (frankly) undisciplined in the way it collects and stores information.

You will have noted above that I said that anyone can create an XML schema; this is true, and this freedom certainly creates the opportunity for conflicting standards. Is such an accessible technology simply a recipe for archaeo-anarchy? Not at all, because there is an entire subset of technologies that are designed to facilitate the process of data transformations from one XML format to another. While the process still entails that a 'mapping' between schemas that is created manually by someone familiar with both; the mapping itself can be read by most XML software applications for large-scale data transformation. ArchaeoML, which Mr Eiteljorg references, can be converted into any other XML format, and the other way around. The problem of conflicting data standards, while it still exists, is no longer the insurmountable problem it used to be.

DIY Data Schema

XML makes all of these wonderful things possible because schema document the kind of information being stored (e.g. "text"), their relationship to other data (e.g, "a property of the artifact"), and a description (e.g. "the type of artifact, usually drawn from the MDA Object Type Thesaurus"), all in machine-readable and human-readable form.

The machine readability is important, and this is where the comparison of database dumps documented by ASCII (text) files to XML simply falls over: text documentation of the kind to which Mr Eiteljorg refers is not standardized, is frequently undocumented, and therefore almost entirely unreadable by machines. Machine processing is utterly essential to the long-term preservation of archaeological data because only machines (not graduate students) can realistically retro-process the thousands of archaeological layers on a site which give a single artifact its context seventy-five years after the excavation finished.

It is also worth noting in this context that the hierarchal and 'tagged' format of XML makes for better long-term data storage, encapsulated self-documentation, and data exchange. Take this example of a 'description' element from MIDAS XML for a hillfort in the hypothetical County of Westshire, UK:

Here we see that the monument is known by two names and has two different identifiers; the use of properties allows us to comment on the currency, preference and source of these identifiers (the XML schema allows its authors to indicate whether one or many names or identifiers are allowed in this context). The database equivalent, restricted to rows and columns in a table, does not permit the same depth of information to be stored in a single file with the same ease.

A final example of how flexible and self-contained XML data structures can be: here we record the names of the places where the monument can be found ('namedplace' is just one element of the MIDAS spatial schema):

The increasingly XML savvy amongst you may have noticed that the above 'namedplace' element permits a very loose definition of a 'location': instead of dictating elements called 'county', 'parish', and 'district' we have defined a loose 'location' element and provided a property ('type') allowing us to define what kind of location is being described. Why? Geographical units are too diverse to be standardized -- cadastral units are commonly used in Europe, while a US and a UK 'county' are completely different entities. Instead of making semantic compromises such as "a UK County = a US State", or attempting to include all known contemporary and historic geographical units across the globe, we can create one element and modify it by its property value. When a new geographic type needs to be added, we can add that value to the list of allowed types, without the need to change the data structure itself. Can we do this with databases? Yes. Can we do it with the same ease and elegance? Not even close.

More Than Data