[ I did add a tag to version 0.4 for the purpose of housing such processing instructions. The tag I chose is <Handling> but already I'm thinking this should be changed to <Processing>. This will need further expansion to establish the children or data types that could be housed within this "processing" portion of each shot. Send some ideas on what you think appropriate tags of flags should be. I'll also be more liberal with the <Comment> tag. It should basically appear in every major subsection of the file hierarchy.

[ At this point in the game the product is so underdeveloped that I can't attempt to enforce compatability between versions 1, 2, and 3. But in the future I agree, backward compatability is a design goal. Compatability will become very serious when we get to a version 1.0, which should represent the "baseline" implementation from which all future work builds. I'm using DataFileVersion now at the suggestion of others to keep track of where we are in the development process. In the future the data inside this tag could be used by an application developer to understand what types of data might appear in a given XML file. For example, v1.0 might not support cave diving survey data, but maybe version 2.0 will. An application could gain some basic information based on that simple element. DSK ]

[I'm starting to think the same thing, too. I threw the <EquivalentStation> in there to see how it would work. It is nice having it in the context to which it applies, i.e. within the <From> or <To> tag pair that it describes, but I'm having second thoughts. There's also merit to placing it at a "global" level as you suggest. Further though, there's the talk underway in the UIS discussion for using XPointer and Xlinks to associate data elements in one location (or file) with data elements in another location (or file). This will innevitably be one of the thornier issues to work out. I'm not wedded to what we have now, but I'd like to keep it there for the time being. Atleast until some more thought and research can be brought to bear. DSK]

[Great one, thanks. I assume accruacy will be an attribute of each type of instrument (compass, clino, tape, etc.). There fore I'll add a tag like <Accuracy> to each of the "instrument" element structures, right alongside the <Correction> tag. DSK]

[I think this is a good call too. And I'll up the ante. Since we're placing data at the global level we should naturally create the ability to override it at the global level. E.g. suppose for some reason someone sneaks a shot into the middle of the survey that isn't decimal feet, but is instead feet and inches. A tag incorporated in that shot would tell you the units used for that particular shot and allow the processing software to deal with it accordingly. If not local units were indicated for a shot then the global units would be used. DSK]

[Actually, this is already in there. If you look immediately below the tag <StationName> you'll see it. But this brings up a point I've been thinking about. I'm not really pleased with the method I've used to organize the data of a survey. What we have here starts with a highlevel <CaveSurvey> that contains <Shot>s, each of which contains a single <From> station and a single <To> station. This is a decent hierarchical representation of a cave survey but there may be some method of crafting a less cumbersome structure. Something similar to what gets entered into the survey book. I've got to think about this one more. But suggestions would defintely be helpful here. DSK]

[OK, I need my soap box for this one. Here's a very clear instance of mixing presentation into the survey data. I agree that cavers want to see their data "presented" in exactly the same way they entered it into the "editing application" but tracking the settings of that "presentation layer data" should be handled seperately from the storage of actual cave survey data. Those presentation settings should be recorded for later use, but they should be recorded in an "application data" file, and not the "survey data" file. For instance, the application developer could save the user's "Editor Appearance" configuration settings in an XML file called EditorSettings.XML. But there's no reason for those settings to go into the actual CaveSurvey data file. That would introduce exactly the kind of data that some other cave survey rendering program would view as unnecessary. Please see the comments on this topic in my rant titled " Data Quality Comments " below. Soapbox off. DSK]

[Differentiating between surveys was suggested buy someone else previously (maybe you). But I haven't put much effort into it just yet. The difficulty is knowing when you actually go from below ground to above ground. Unless you use two different surveys (with different names) it could be different. For instance, if I survey my way out of an entrance, down the valley and into another entrance, I haven't done anything to indicate I'm out of the cave. I know this normally doesn't occur but I use it to illustrate that surveying below ground differs little from surveying above ground. You just lose the left, right, up and down. One way of dealing with this is to add a comment, either globally if the entire survey is above ground that tells you this is a surface survey, or locally if you just have a few shots within a survey that are above ground. This could be taken to the other extreme too, how do we know when we're looking at a regular cave survey versus a diving cave survey?

Knowing how to handle a shot, i.e. whether it counts in the system length, is a good one. I consider this kind of thing to be a processing instruction, that while not recorded in the cave, definitely applies to how the survey data should be handled (and is not a presentation issue like order of entry). The difficulty here is coming up with a convention that software developers can all agree upon. This one borders very closely on proprietary extenstions but I'll try to get something into the next version that address this.