From: Ralph Hartley (hartley_at_aic.nrl.navy.mil)
Date: Fri Feb 23 2001 - 20:16:02 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id UAA32176 for cavexml-outgoing; Fri, 23 Feb 2001 20:12:29 +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 UAA32172 for <cavexml_at_cartography.ch>; Fri, 23 Feb 2001 20:12:28 +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 OAA06077 for <cavexml_at_cartography.ch>; Fri, 23 Feb 2001 14:12:31 -0500 (EST) Message-ID: <3A96B6F2.60603@aic.nrl.navy.mil> Date: Fri, 23 Feb 2001 14:16:02 -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/20010124 X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Re: Stations are primary References: <Pine.GSO.4.05.10102221318120.26224-100000_at_cor.oz.cc.utah.edu> <3A9671FD.8070506_at_aic.nrl.navy.mil> 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
Richard Knapp wrote:
>> The more I have thought about CaveXML, the more I am drawn to the
>> conclusion that the primary element must be the station, not the shot
>
>
> Are they primary before or after the data has been crunched?
Actually, I think they are primary at **all** times and purposes,
**except** when recording shots in the survey book. When actually
mapping the stations are what counts. It is common to permanently mark
stations in a cave, does anybody mark shots? It is vitally important to
know when two stations are the same; but, except for some advanced error
correction, it isn't important to know if two pieces of data are from
the same shot (between the same pair of stations).
> Granted, the stations are central when there are precision points
> known (or the entrance). Other than that, a station is nothing more
> than a semi-imaginary point we create to support the shot and the survey.
Or a shot is just a set of measurements used to determine the relative
positions of the stations, and an imaginary line we create to support
the stations and the survey. Which is more important for clapping? Your
left hand, or your right hand? But stations, unlike shots, **must** have
an **identity**. That is, it must be possible to determine if two
references to stations refer to the same station. (If anyone thinks
shots should have unique identities too, I have no opinion yet. Perhaps
as an option ...)
>
>> An editor, when a shot is added, needs to check if the stations
>> already exist. If so it uses the old id for the station, otherwise it
>> needs to generate a new station element.
>
>
> This statement seems to contradict the following statement (from the
> beginning of the e-mail)
>
>> Also, different programs may each need to have their own names for
>> the stations, and the names may not be compatible (one may require
>> names to start with a letter, another may use numbers only), or the
>> names might overlap (foo and bar both have a station named "1" but
>> they are different stations).
>
>
An editor still needs to understand how **its****own** names work.
> I keep coming back to examples in Survex (and BCRA stuff) and the
> check for an existing station in the currently known list would always
> cause problems.
How do those programs work now? They must have **some** way to tell if a
station is new (within a file) or is the same as a previous station. If
they didn't, how could they do anything with the data? If station names
are assumed unique within (Survex) files (1, 2, 3, ...) that's fine,
base the station IDs on those. When merging files, maintain that
uniqueness by prepending the file name (or a hash of it), except when
you know (by whatever means you use now) that two stations in different
files are the same (this is just one possible implementation). You can
keep track of file names by having one big namesystem with names that
combine filename and number, or separate namesystems for each file.
If I am wrong, and there is really something in my proposal that does
not allow any existing program to do what it has always done (except for
during conversions), then that is a bug and CaveXML needs to be fixed
(preferably sooner not latter).
> I don't think the format should rely on a certain program to correctly
> validate the data before storage; the DTD or Schema is responsible.The
> format should be able to stand on it's own without a special application.
I agree. As far as possible no nonstandard tools should be required to
check the validity of a file. In this case none are, because uniqueness
is part of the definition of IDs and IDREFs.
> <Shot> <!-- from FOO1 to FOO2 --!>
> <From station="2">
> <to station="1">
> ...
> </Shot>
>
> I'm not too good with DTDs.
(and there are surely errors in that one, and in the sample fragment)
> Are the values for station IDREFs?
Yes. Independent of whether "from" and "to" are elements or attributes,
stations should only be referred to by IDREFs. That way they are unique
in any valid (according to the DTD or schema) file.
Ralph Hartley
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET