From: Ralph Hartley (hartley_at_aic.nrl.navy.mil)
Date: Wed Jan 24 2001 - 22:26:18 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id WAA10705 for cavexml-outgoing; Wed, 24 Jan 2001 22:23:40 +0100 Received: from sun0.aic.nrl.navy.mil (sun0.aic.nrl.navy.mil [132.250.84.10]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA10701 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 22:23:40 +0100 Received: from aic.nrl.navy.mil (pc31.aic.nrl.navy.mil [132.250.84.181]) by sun0.aic.nrl.navy.mil (8.9.3+Sun/8.9.3) with ESMTP id QAA03088 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 16:23:42 -0500 (EST) Message-ID: <3A6F487A.8070701@aic.nrl.navy.mil> Date: Wed, 24 Jan 2001 16:26:18 -0500 From: Ralph Hartley <hartley_at_aic.nrl.navy.mil> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20010122 X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Re: Splitting SHOT into constituent members References: <00bf01c0863d$ace66040$0a3c10ac_at_gordon> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Julian Todd wrote:
> 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.
You mean the shot is acting as a default, with respect to things within
itself and overrides with respect to things that contain it. The value
of the attribute is defined to be the innermost definition.
> 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/>
Lets make that
<distance from=88, to=88a, value=66, instrumenttype=tape, units=metres, serialnumber=2267zz, operator=Boris, date=March99/>
Which would be equivalent to:
<surveytrip date=March99>
...
<distanceinstrument instrumenttype=tape, units=metres, serialnumber=2267zz, operator=Boris/>
...
<shot from=88, to=88a>
...
<distance value=66/>
...
</shot>
...
</distanceinstrument>
...
</surveytrip>
Here "serialnumber", and "operator" may also be attributes of other
readings (such as bearings) but distanceinstument only provides values
of them to distance measurements. Perhaps the distanceinstrument could
even be replaced by:
<instrument modality=distance, type=tape, units=metres, serialnumber=2267zz, operator=Boris/>
which provides values to any nested measurements of the given modality.
> Ultimately, the general caveXML parser could be a very slim object indeed.
Which is good, as long as the parsed version is not too difficult to
use. This sort of structure should be fairly nice if the parser can
easily provide the information in whatever hierarchy a given program needs.
I haven't really worked with xml so I don't know how much of this is
compatible with the philosophy and capability of existing tools.
Ralph Hartley
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:53 CET