CDFT: survey/xml task list

[devinkouts@earthlink.net]

All,

>>* decide on using a DTD, schema, or both.
>
>If I have a vote, I would opt for Schema. They are valid XML documents,
unlike DTDs. They also
>seem to provide more flexibility -- maybe it is just ease -- in
defining the document structure.

I submit that both DTD and Xschema may be useful. I'm somewhat less
experienced with Xschema but can read the writing on the wall, it will
likely overtake DTD any minute now. Until that moment, or until joint
concensus feels DTD are of no value, I move that we attempt to use both
DTD and Xschema to describe the valid contents of an XML file used to
convey cave data. I've actually just begun work on the proposed DTD to
describe my own efforts at developing an XML structure to contain survey
data. I will submit it for consideration by this group.

>> * decide on the basic methodology for data transfer and archiving,
e.g. XML.
>
>Does archiving include the use of the file in place of a raw data file
(ie. Survex .svx or COMPASS
>.DAT file)?

As Olly pointed out, .svx and .dat files do contain human decipherable
cave survey data, and I don't see them being quickly abandoned in favor
of XML. For the foreseeable future I envision the most popular use of an
XML standard for cave data would be the transfer (and archiving) of data
in a common form. Developers of cave survey rendering software will, at
their discretion, choose to implement the XML standard as their
preferred method of writing data to a file over their existing
proprietary method. I think the only way this will come about however is
if we can do such a good job with the standard that it becomes worth
their while to employ it.

>Since not everything will be covered, should means of using XPointers
and XLinks be covered
>as well?

In some of the general feedback I've received on my own efforts in XML a
recurring need has been the ability to reference data located in other
files. Examples include two caves which are surveyed and stored in
seperate files, and then suddenly connected. Another might be the need
to emply seperate files to contain certain segments of a cave's survey,
and linking those surveys together by some means. XPointers and XLinks
are clearly on the table to address these requirements.

>Two known websites which show existing work which has been done are:
>
>Mike Lake:
>http://www.speleonics.com.au/cavescript/
>
>Devin Kouts:
>www.psc-cavers.org/xml
>
>Others?

The version 0.2 release of Cave Survey data in XML posted on my web site
should be handled with care. It is incomplete and not even well
organized. But that's the purpose of iterative development, to mature
the work and get the bugs out. A version 0.3 will be posted soon and
available for perusal or comment.

Other considerations:

1. It will be necessary to establish the baseline form of an XML
document used to describe Cave Data. I'm already receiving feedback on
my work that suggests introducing proprietary extensions that would be
useful to a minority while encumbering the majority. Because of XML's
extensibility a baseline, once established, can be extended by
proprietary methods without affecting the fundamental data recorded by
the cave data file.

2. I would not think it wise to squash the XML structure designed to
carry survey data together with the structure intended to carry cave
mapping data. This is conjecture on my part since I haven't experienced
too many examples of the latter, but I would rely on experience that has
taught me to segregate data to the greatest "Normal Form" that makes
sense. If the two types of data are readily different from each other it
would probably be wise to store them in two different XML file
structures, and implement the ERD Peter has proposed to link their
respective data with XPointer/XLink solutions.

3. "* decide on the range of fields which we need to consider in a
survey data transfer:" This item from Peters list begets a requirements
discussion. I propose folks submit their ideas of which elements should
be recorded in an XML file of cave data. The results can be hashed over
and worked into a skeletal structure for implementation.

Devin Kouts