From: Michael Lake (mikel_at_speleonics.com.au)
Date: Mon Feb 26 2001 - 13:04:04 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id NAA13276 for cavexml-outgoing; Mon, 26 Feb 2001 13:06:45 +0100 Received: from iggy.triode.net.au (IDENT:root_at_iggy.triode.net.au [203.63.235.1]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA13272 for <cavexml_at_cartography.ch>; Mon, 26 Feb 2001 13:06:43 +0100 Received: from speleonics.com.au (mikel_at_dm1-4.triode.net.au [203.63.34.5]) by iggy.triode.net.au (8.11.1/8.10.1) with ESMTP id f1QCAhG14574 for <cavexml_at_cartography.ch>; Mon, 26 Feb 2001 23:10:46 +1100 Message-ID: <3A9A4634.7C1FD1F6@speleonics.com.au> Date: Mon, 26 Feb 2001 23:04:04 +1100 From: Michael Lake <mikel_at_speleonics.com.au> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.14 i686) 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> <3A958410.9080404_at_europa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Hi All,
Here are some thoughts on xlink/xpointer and how they may offer an
alternative to idrefs.
I am not against unique id's and using idrefs. I think the equivalence
attribute or element is a good idea and would work well. xlinking is an
alternative road.
Sorry that there are lots of bits here.
Garry Petrie wrote:
> You still have the problem forming connections between multiple data sets, i.e. real
> stations that are in common.
file://spider_cave.xml#root().id(A3) refers to the station with idref=A3
file://spider_cave.xml#root().descendant(station, name, "big rock")
refers to the same station idref=A3 with name name="big rock"
Ideas only above and my Xlink/XPointer is prob wrong but I just want to
point out that we shall be able to refer to any element quite easily.
> Practically, the unique station names are only useful for detecting name aliases and
> providing references through out the CaveXML file. When reading the data of a station,
> memory is allocated for the structure to contain the data. The physical address, pointer,
> of that structure becomes your ID. Once the data is read in and properly sorted, the ID's
> from the CaveXML file no longer serve any purpose.
I think Garry has an important point here. With unique idrefs what will
use them? If the editor creates them but they are not used by programs
then that does place unneccssary data in the XML file.
Ralph Hartley penned...
> An "Equivalence" element is still needed because there has to be a
> nondestructive way to say that two stations are the same.
..........
> entry tools would use the unique names to identify stations, reserving
> the Equivalent element for use when the identification is uncertain, or
> possibly when the stations are in other files (which cannot be assumed
> to respect our unique names).
Thats where you can use an Xlink/Xpointer. Its nondestructive because
you do not have to add anything to the station elements. ie
<EQUATE
StationLink="#mycave.id(A3)"
StationLink="#mycave.child(station, name, ""big rock)"
StationLink="#mycave.ext.88">
</EQUATE>
we don't add anything to staion A3, or station "big rock" or station 88.
It's all in the xlink/xpointer - and this can all be in another file if
you want! So you can rearrange what stations are the same as other ones
just by editing xlinks.
Part of the schema that describes this is like:
<complexType name="equate" >
<attribute name="equate" type="xml:link" use="required" />
</complexType>
(PS. I don't quite know how to do this correctly yet)
Ralph said...
> The central point of my proposal is that
> stations need to be referred to by IDREFs, which are required to be
> unique.
..........
> understanding the data, because when writing the CaveXML file they have
> to convert those names to IDREFs, which is the only way to refer to
> stations in CaveXML.
as above you can use xlink stuff. Thats how I was planning to handle the
*equate used by Survex.
*** NOTE That IDs must start with a letter **** so you can't have
id="2". Thats why I have prefixed it with A.
John Halleck scribbled...
> What unique numbers (in a range without gaps) buys you is the
> ability to update and combine cleanly and effeciently.
I presume that when you combine two survey files from two survey teams
the processing software will have to take the two sets of ids which may
have been unique to each file and renumber it so that they are unique to
the combined file? In Survex I often have a few dozen files for a cave.
Each survey has a name and the survey stations are scoped by the section
they are within using *begin muddyBit and *end muddyBit.
Ralph again....
> 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?
!!! LOVE that analogy Ralph :-)
> 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 ...)
Interesting. This is philosophy here :-)
I think stations, like shots, are just a mathematical construct used in
surveying. Sometimes I will have a station that is just a temporary
point in space, say a the end of a tape hanging 1m down from the tip of
a stal - just cause it gave a good point to sight to/from. But its an
imaginary point in space. Its no more real than the shots in this case.
Also if one is surveying by triangulation and Theodolite surveys using
included angles and lengths then its the shots that make the survey and
such a program would not necessarily even need to use station names. It
could construct the survey shape from the shots alone. Its just that in
most cavers survey stations are usually real things like stals and rocks
and we name them.
and Ralph rabbited on :-)
> 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.
Survex uses *begin <some name> and *end to scope stations. So you can
call a station what ever you like within that and use the same name
outside that scope. The begin/ends can be nested as well.
> 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.
Survex I suppose then effectively prepends those begin names to each
station station making a heirarchical system. It would not use unique id
refs and would require the equivalent of a nested name scoping thingy
like what I have in my mysurvey.xml example file at my web site.
Final thought by me.
I can see that there are two ways we could go here. Using IDs and
xlinks. Can one use both and provide two mechanisms for cave survey
programs or would that end up forking programs in to the "unique id
camp" and the "Xlink" camp ?
and thus spate John....
> I'll still argue for a numeric ID (with some prefix) on grounds of
> symplicity of algorithms to combine the files...
I think some programs would find it useful.
Mike
-- -------------------------------------------------------------------- Michael Lake Active caver, Linux enthusiast and interested in anything technical. Safety Convenor, Australian Speleological Federation Owner, Speleonics (Australia) --------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET