CDFN: Name and purpose

Peter MATTHEWS matthews@melbpc.org.au
Wed, 10 Jan 2001 21:17:17 +1100


I hope you don't mind my changing the name of this post to better reflect
the thread which has developed about the name of the transfer format and
what it should cover.

Format Name
===========

Is "Markup Language" the best term to use for our format? It has been
commonly used for this kind of thing of course, e.g. "Chemical Markup
Language" among many others, but there are benefits in using a less nerdish
term. I can see that many of the people who we will need to use and promote
the use of the format in future, people whose job is cave management and
cave/karst research, not cave surveying and/or data formats, saying,
"Markup Language? Huh, what is that?" Whereas if we use plainspeak and call
it an "Exchange Format" it is immediately apparent to anyone at all what
it's main purpose is, even though of course it is in fact a markup
language. We also need to keep in mind that what we are doing will lead to
a format not just for cave surveying, but for transferring and storing the
whole range of cave and karst data, hence the wider user base referred to
above.

This leads on to what we will be actually covering by the name. Earlier
postings have referred to karst vs. caves, underground vs. surface, survey
vs. maps. vs. karst,  caves vs. mines. And Mike Lake recommended separate
schemas for surveys and for maps to avoid bloat. I doubt we will find one
short term which will perfectly cover all these.

However on the basis that the transfer format as a whole should cover all
these, even though we may have separate DTDs and/or schemas for sub-groups
such as mapping and surveying, then I think the best approximate fit we are
likely to get for the general usage term for the overall format, and taking
into account the markup/exchange term discussed in para 2 above is:

"Cave & Karst Exchange Format" - or CKX for short.

CKX is reasonably easy to say (for English speakers at least!), has not
been used before in speleo-land to my knowledge, and covers the whole range
of what we are likely to be dealing with eventually.

What do you think? Any problems forseen with settling on CKX?


Purpose
=======

The prime purpose for the format as I have understood it is for the
transfer and storage of data, and in an independent format, rather than for
a format that the data can be directly used from. Having said that, I
realise that some programs might introduce a pre-processor function into
their process so that effectively the stored data can be "used" directly.
However this is a thing for developers to handle, not for this group to be
concerned with, except to be aware that this is a probably desirable
possibility. 

And of course once we have the data in an agreed XML language, the number
of applications for it is quite open-ended. So I don't know that we should
be trying to concern ourselves with covering all the possible uses, rather
we should just concentrate on the transfer and storage functionality, while
at the same time being mindful of not closing off its usefulness to a wide
range of actual uses. 

Have I got this wrong, or are there other basic purposes we should be
explicitly addressing as well as transfer and storage/archiving?

Peter