From: Julian Todd (julian_at_ncgraphics.co.uk)
Date: Wed Jan 24 2001 - 20:41:36 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id UAA10348 for cavexml-outgoing; Wed, 24 Jan 2001 20:44:07 +0100 Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA10344 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 20:44:07 +0100 Received: from [62.7.12.204] (helo=gordon) by tungsten.btinternet.com with smtp (Exim 3.03 #83) id 14LVpu-00072C-00 for cavexml_at_cartography.ch; Wed, 24 Jan 2001 19:44:08 +0000 Message-ID: <00bf01c0863d$ace66040$0a3c10ac@gordon> From: "Julian Todd" <julian_at_ncgraphics.co.uk> To: <cavexml_at_cartography.ch> Subject: Re: Splitting SHOT into constituent members Date: Wed, 24 Jan 2001 19:41:36 -0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Well, at least people are thinking about it as opposed
to dismissing it out of hand.
Here is a revised proposal that gets the best of both worlds:
Step 1: make every measurement record in the XML
file self-contained.
In practice this means including "from" and "to"
attributes into every tape, compass, clino (or distents,
azimoth, beering) record.
It will also force a self-contained cross section definition
records similar to the kind I have proposed earlier.
Step 2: You can -- optionally -- bracket a series of
these measurements inside a
<shot></shot> pair.
Possibly, the <shot> could contain "station1" and
"station2" attributes rather than the misleading
"from" and "to" ones because some of the measurements
might be backward sights.
Maybe you could simply require that the number of
distinct stations referenced inside the <shot>
grouping is exactly 2.
Consequently, measurements will not have to be forced to
conform to the standard shot structure if they don't fit it.
Likewise, the shot structure won't need to be generalized to
take account of all the different ways of measuring things.
It will apply only where it naturally fits.
You could even hide a self-contained cross-section
definition within a <shot> bracket without irritating me
too greatly!
.... Further thoughts [Attribute Over-riding]
I might still be happy with <shot> having the attributes "from"
and "to" and omitting those parameters from the contained
measurement records. This gets us almost back to where
we started. However, what I am saying is that
<shot from=88, to=88a>
<tape value=66>
<shot/>
should be equivalent to:
<tape from=88, to=88a, value=66/>
(or, more strictly, <shot><tape from=88, to=88a, value=66/></shot>).
The shot record is acting like an attribute over-ride:
The <tape> record fetches its "from" and "to" attributes
from those in the <shot> bracket containing it if they are
not specified, and one exists.
This attribute over-riding method can solve other
problems such as specifying the tape units.
Suppose we agreed that the full distance record was:
<tape from=88, to=88a, value=66, units=metres, tapeserialnumber=2267zz,
tapeoperator=Boris, date=March99/>
We could -- equivalently -- wrap the all the tape measurements
(and all the others too, though they wouldn't pay any notice) inside
another attribute over-ride bracket:
<surveytrip date=March99>
...
<tapeinstrument units=metres, tapeserialnumber=2267zz,
tapeoperator=Boris/>
<tape from=88, to=88a, value=66/>
...
</tapeinstrument>
<surveytrip/>
Ultimately, the general caveXML parser could be a very slim object indeed.
All it would need to know is the full parameter list for each
different type of measurement (distance, depthguage, GPS...
there's about half a dozen), and the names of the commands which
it should interpret as being an attribute over-ride type.
It would not need to distinguish between them in order to
expand everything into a big database. You'd only later bother with
rules like: <surveytrip> can't have a "from" attribute.
Anyways, with this organization, it suggests that we should
first agree on a complete set of attributes for each commonly
used type of measurement.
Then we should define the names of the attribute over-ride
types, and the subsets of attributes they should over-ride
(one of these will be the <shot> type).
Then we should define other misc restrictions to be
enforced within these attribute-override brackets.
For example, two distinct station references within a <shot>,
a <surveytrip> can't be inside another <surveytrip>, and
so forth.
Does this sound like a plan?
Who'll be first to make a stab at the complete set of attributes for a
single
distance measurement (be it a tape, laser, whatever)?
Julian Todd.
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:53 CET