From: Kouts, Devin S. (DEVIN.S.KOUTS_at_saic.com)
Date: Tue Sep 04 2001 - 16:34:10 CEST
Received: (from mdom_at_localhost) by karto.ethz.ch (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id f84EQgl04290 for cavexml-outgoing; Tue, 4 Sep 2001 16:26:42 +0200 Received: from portal.east.saic.com (portal.east.saic.com [198.151.13.15]) by karto.ethz.ch (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with SMTP id f84EQfQ04286 for <cavexml_at_cartography.ch>; Tue, 4 Sep 2001 16:26:42 +0200 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for karto.ethz.ch [129.132.127.159]) with SMTP; 4 Sep 2001 14:29:24 UT Received: from [149.8.64.19] by mclmx.mail.saic.com; Tue, 4 Sep 2001 10:29:10 -0400 Received: from MCL-ITS-EXIG01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01. (NAVGW 2.5.1.12) with SMTP id M2001090410274713652 for <cavexml_at_cartography.ch>; Tue, 04 Sep 2001 10:27:47 -0700 Received: by mcl-its-exig01.saic.com with Internet Mail Service (5.5.2653.19) id <Q0ZFNMZF>; Tue, 4 Sep 2001 10:34:11 -0400 Message-Id: <881CC7991757D51196CF00508BCFE591016B638A@mcl-its-exs03.mail.saic.com> From: "Kouts, Devin S." <DEVIN.S.KOUTS_at_saic.com> To: cavexml_at_cartography.ch Subject: RE: Nested Surveys Date: Tue, 4 Sep 2001 10:34:10 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Yes, Yes, Yes!!!
This goes directly to the heart of the point I was arguing several months
ago. The ability to nest surveys is absolutely necessary as you illustrate
below because of the nature in which surveys occur and are organized. Too
many people try to define a survey in one way or another (e.g. the survey is
the whole cave, or the survey is just one passage, or the survey is
everything collected in one trip). They're all accurate uses of the term and
should therefore be accomodated by a data structure that is equally
flexible.
To be that flexible you must recognize a survey for what it is fundamentally
(a collection of survey shots) and realize that a survey can have other
surveys nested within it. Then you can achieve a cave "Survey", that also
accomodates individual passage "surveys" or one day's worth of "survey".
Richard's example of <SurveyGroup> illustrates how clumsy it can become to
create a new name for each level of your survey collection hierarchy. An
equally clumsy tag would be <SubSurvey>. Just what would you do when you
needed to place another Survey under your <SubSurvey>, create another tag?
No. Just create a new <Survey> with all the same properties of any other
given survey.
As an option to grouping surveys you might consider a structure that uses
Xpointer to give access to surveys in a predertermined order. For instance,
you might have created surveys sequentially:
<Survey>
<Survey> A </Survey>
<Survey> B </Survey>
<Survey> C </Survey>
</Survey>
But you could reorder them with an Xpointer to access in any fashion you
choose:
<Survey>
<Survey> Xpoint to Survey C </Survey>
<Survey> Xpoint to Survey B </Survey>
<Survey> Xpoint to Survey A </Survey>
</Survey>
Note that this example maintain the survey nesting construct you describe
below.
DSK
Devin S. Kouts
SAIC Program Manager &
Senior Systems Engineer
703-676-6555 - office
703-966-8448 - cell
703-821-1796 - fax
devin.s.kouts_at_saic.com
-----Original Message-----
From: owner-cavexml_at_karto.baug.ethz.ch
[mailto:owner-cavexml_at_karto.baug.ethz.ch]On Behalf Of Richard Knapp
Sent: Sunday, September 02, 2001 10:16 AM
To: cavexml_at_cartography.ch
Subject: Nested Surveys
I've been thinking about nested surveys... again. In my current (play) DTD,
I'm using a SurveyGroup element to allow
multiple surveys to be grouped together. However, that only allows one level
of nesting:
<SurveyGroup>
<Survey>
</Survey>
<Survey>
</Survey>
</SurveyGroup>
I think, for easy of coding and better capability, it would be better to
allow surveys to be nested directly:
<Survey>
<Survey>
<Survey>
</Survey>
<Survey>
</Survey>
</Survey>
<Survey>
</Survey>
</Survey>
The "Colorado Survey Standard" attempt allowed nesting like like the
SurveyGroup example. However, I think Survex
has a more robust grouping scheme by allowing multiple begin/end pairs. With
XML, nesting should be easier (at least if
the document is properly formed).
This isn't a large change in DTD code but it is a fairly significant change
in functionality.
(old DTD code)
<!ELEMENT Survey (%SurveyHeader;, Data)>
(new DTD code)
<!ELEMENT Survey ( (Survey)+ | (%SurveyHeader;, Data) )>
The one thing the SurveyGroup does provide is nesting other than by Survey.
For instance, Surveys could be grouped
because of their location - entrance crawl, BFR, Left Hand Tunnel. However,
a SurveyGroup cannot - at this time -
contain another SurveyGroup which is a little limiting.
My opinion (currently) is I like the nested Surveys more than the
SurveyGroup. It's easier to follow, allows more nesting.
The downside is if used to create areas in a cave, it really isn't a proper
name (not a location or anything if that makes any
sense).
If this works, I think I could also get rid of my Surveys element. It was
used to break the raw data away from other cave
data that could be included later: pictures, mineralogical inventory, bio
inventories, etc.
What do you think?
- Richard Knapp
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b30 : Wed Jan 23 2002 - 17:06:45 CET