CDFT: survey/xml task list

[Michael Lake]

Richard Knapp wrote:
> (My first time on this so please be forgiving...)
> >* 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 would agree. I started with DTD's back in December 1999 but thats when
there was not much info on Schemas at all. Since seeing Martin Lavertys
recast of my DTDs into Schema form I can see the benefits. I'd go for
Schema too.

> > * 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)?

I see raw data files being converted to an XML format for archiving and
back again to whatever form is required with style sheets or a parsing
application.
However we could have an XML element that contains binary raw survey
data.

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

I would include a specification for how such could be used. Eg I have
included such in my documentation on CaveScriptXML as I see them as a
way to link survey points together ie when you equate survey stations
from different surveys and say they are the same physical point. Doing
this with XPointers and XLinks could be very neat.

> For work in progress, there is www.geocities.com/richard_knapp/projects... 
> at least until a new domain is opened.

Space on my domain is available for putting this work up on it ie
www.speleonics.com.au/~anything
Its permanent and reasonably fast. 
I don't think we need to go for a domain specifically for this. 

richard_knapp mentioned on his site
"...For instance,
there is no "official" name for this format. Tom was going to call it
KML for Karst Markup Language but both the .org and .com domains have
been taken. CML is used by Mel Park so that is out. Ideas are welcome
and all(reasonable) names will be posted.
Names submitted as of 30 Dec, 2000:
    CaveXML 
    KML 
"end quote.

What do we want this to actually be? A Karst Markup Language is much
broader than a cave markup language for surveying. My CaveScriptXML was
named that because what I was aiming for one markup language that would
just encompass cave survey (CAVESURVEY) and a separate one for maps
(CAVEMAP). Separating them like this I think is good. A bit like why you
have databases made up of tables.
(The two together form CaveScript named after PostScript as the two
would be used together to form the language to describe and draw cave
maps in the same way that PostScript describes documents)

A Karst Markup Language is far more extensive. It covers hydrology,
geomorphology, landforms, etc. Have a look at the UIS Field Definitions.
I would have a CAVESURVEY CAVEMAP Schemas which can be integrated into a
future KARST schema rather than a monolithic or bloated schema that
tries to cover too much. What do you think?

Mike
-- 
--------------------------------------------------------------------
Michael Lake
Active caver, Linux enthusiast and interested in anything technical.
Safety Convenor, Australian Speleological Federation
Owner, Speleonics (Australia)
--------------------------------------------------------------------