Ralph Hartley wrote:
>
> Here is a list of some of the things CaveXML needs. Some may be
> mutually exclusive.
>
> 1 It must be permitted to include information that not all programs
> can, or wish to, understand.
Information (data) in CaveXML falls into two categories, (1) part of the
CaveXML baseline and, (2) extenstions to that baseline. Either type can
handle your request, but I submit that the baseline should be somewhat
constrained to the majority of data that we historically record. FOr
instance, embedding an image file into the data file goes well beyond
what we do now, but seems like a logical extension to CaveXML. Make such
a capability an extension that over time could be moved into the baseline.
>
> 2 It must be possible - preferably easier than the alternative - to
> preserve all information (including information the converter does not
> understand) through a round trip to/from another format. If this could
> be done even if the file was edited in the other format, that would be
> a Good Thing.
This is a function of how an application handles a CaveXML formatted
file. If a program uses a CaveXML file, does some processing, and then
modifies the original file (resulting in a loss of data) then it sounds
like an issue for the application user to consider. I.e., do they want
to keep using that application or not?
Valid data must flow from an authoritative source. If I give you the
Twisted FIssure data in CaveXML and you use an app that bungs it all up,
no big deal. Just contact me (or the authoritative source) and I'll give
you another copy of the original data.
>
> 3 It should be possible to include enough information in a file to
> allow a round trip from/to another format, reproducing the original
> exactly. Conversion programs don't have to do that, but it should be
> possible. For some formats, this may be impossibly hard.
Not sure I follow you on this. If I have a complete record in the first
CaveXML file and some application converts it to another XML (or other
file type) and then converts it back to CaveXML, any resultant data loss
is the fault of the application, not the original CaveXML file.
What am I missing here?
>
> 4 It must be possible to include enough information to reproduce the
> survey notebooks, at least in all meaningful respects (mud stains may
> be excluded).
Agreed, within reason. Reason being those things that really count to
surveyors and that appear in many of today's proprietary formats. See my
comments about CaveXML baseline above.
>
> 5 It should be possible to exclude any information from a file that is
> not needed for the task at hand.
Again, this is a function of the application processing data from a
CaveXML file. Once the file is parsed and available in memory it is the
applications choice as to what is uses from that collection of data.
>
> 6 There should be a standard way to record any information that is
> common to at least two programs.
I think you're talking about capturing those things that are commonly
captured by most proprietary data storage formats. If that's so then I
agree. This is the reason I did the matrix analysis of existing
proprietary formats, to derive requriements for "common" information
types (see it at www.psc-cavers.org/xml)
>
> 7 There should be no absolute dependence on details of the survey, or
> data reduction, process (e.g. station naming conventions).
If you're implying that unique id's for stations become a requirement
before you can put your data in a CaveXML file and call it valid, then I
have to disagree. I can easily write an app that reduces cave survey
data based upon the data we collect historically (without unique ID or
IDREF). Things like ID or IDREF should be treated as optional. If your
app needs them to do it's thing, then you can generate them as you need
to. I don't need it so I won't waste the time writing the code.
>
> 8 The format should be as simple as possible.
Agreed. But not at the sake of extensibility. I wrote an earlier email
that described Fat versus Thin protocols. I still recommend building an
early model in a Fot protocol and then "slimming" it down to a "thinner"
protocol once the model has stabilized.
>
> 9 There must be no ambiguity in any data. Any information that is
> required for processing, or interpreting, the data must be included.
Agreed.
>
> 10 The core of the format, that all programs must understand, should
> be as small as possible.
Whatever seems reasonable. A highly subjective goal.
>
> I'm sure there are more. Does anyone disagree that these are
> reasonable goals?
There are many more. I actually put some effort into Requirements
elicitation some months ago when I got the Cave Survey Data in XML
effort rolling. I spoke with many of the poeple who write the apps that
we use to render survey data and got their input. I reduced their
comments into a requirements matrix (view it at
http://www.psc-cavers.org/xml/Requirements.html). You can even read many
of their original comments at http://www.psc-cavers.org/xml/Discussion.html
>
> Ralph Hartley
>
>
>
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:00 CEST