>I am much more on the same page as John Halleck, later passes might add
>_separate_ elements, but these elements certainly could be right next
>to (or nested within) the original, in fact I'd prefer it.
We're all on the same page. If you want to stuff your post processing
data back into the original data file in one neat package that should be
o.k. XML is extensible like that. But that's exactly the point. Those
kinds of construct are "extensions". We haven't even solved the
fundamental issue of what goes into the basic data storage file and
we're already trying to incorporate, closed loops, calculated cartesian
coordinates, etc. What's next, stick the CaveMapXML tags into CaveXML
too?
I believe in a stepwise progression when building solutions such as
this. And data solutions depend upon data flow analysis and data
modeling techniques that our group hasn't seemed interested in
exercising.
Before we get too wrapped up in what "else" we can put in CaveXML maybe
we should solve what goes "first" into CaveXML.
Also, I wasn't attacking your <Group> construct. It is a viable tag. I
just don't feel it meets the requirements to be an early component of
CaveXML. Those requirements, in my view, are: (1) it's a historically
recorded element or construct in 2 or more of the most popular cave
survey data formats in active use today, and (2) it's clearly a unique
construct that can not be accomplished with some other existing
construct.
Yes, this is good stuff.
DSK
-- Devin Kouts Caver Systems Engineer www.psc-cavers.org
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:00 CEST