From: Paul & Eleanor (goodhill_at_xmission.com)
Date: Fri Feb 02 2001 - 07:24:29 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id HAA23862 for cavexml-outgoing; Fri, 2 Feb 2001 07:20:49 +0100 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id HAA23858 for <cavexml_at_cartography.ch>; Fri, 2 Feb 2001 07:20:48 +0100 Received: from slc415.modem.xmission.com ([166.70.2.161] helo=xmission.com) by mail.xmission.com with esmtp (Exim 3.12 #1) id 14OZal-00059w-00 for cavexml_at_cartography.ch; Thu, 01 Feb 2001 23:21:08 -0700 Message-ID: <3A7A529D.BA0EB19@xmission.com> Date: Thu, 01 Feb 2001 23:24:29 -0700 From: Paul & Eleanor <goodhill_at_xmission.com> X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Re: Groupings References: <200102011429.PAA20204_at_karto.ethz.ch> <3A798F58.9020907_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
Garry Petrie wrote:
>
> Richard Knapp wrote:
>
> > This seems to be a practice very common in the US but in Europe most cavers
> > structure the data in a way in which each survey represents a certain
> > passage. The structure of the data represents the topology of the cave and
> > this is the way how the survey editor of software like Cave Render or
> > Toporobot works.
>
> Here is an example of the application driving the data recording. In effect,
> the data set
> will never be larger than the capabilities of the software, which leads
> to multiple data
> sets representing the same object, each tailored to the application.
How did the software get into the picture? Richard said the cave
was grouped into physical sections, not sections useful for the
software.
What are thinking when you say 'capabilities of the software'?
When I read Richard comments I think about real 1 km long dead end
surveys
(back end of some long cave with few branches)
I assume his description would mean that some 'survey', maybe traverse
might be the right word, would define the whole linear passage.
Meanwhile in the US, when one survey party goes home half way down
the passage at station D82, they might return the next month and start
at E1, for no particular reason. D83 is as unique a name as E1 that is
all the American style is worried about.
I recall some of the early Toporobot articles talking about
required organization schemes. They seems impossible to me.
The software doesn't drive surveys the software needs to
deal with the types of real data that is out there.
Garry, I think we are on the same page on this one.
How is naming of stations and surveys imply that there will or will
not be multiple data sets representing the same data? I figure
I can repeat or not repeat anything I want in an XML file. If there
is repeats, there has got to be some tag somewhere that helps the
sender and receiver figure out what the difference is.
> Paul & Eleanor wrote:
> Garry Wrote:
> >> That is the whole point of a relational database, to group data by
> >> attributes.
> >
> > Except we aren't defining a relational database.
>
> A relational database is an application, not data. For example, you can
> freely move data between Microsoft Excel and Access.
These seem to be non-sequitors. How do they relate to
hierarchical marked-up data.
Please explain such gems of knowledge. You need to bring
"The whole point of RDB..." and "you can freely move data" and
connect them to CaveXML and how it should support some
particular feature, because of such obvious or not so obvious
uses of the data in a different form.
-Paul
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET