From: Peter MATTHEWS (matthews_at_melbpc.org.au)
Date: Tue Jul 16 2002 - 09:50:27 CEST
Return-Path: <owner-cavexml-outgoing_at_ethz.ch> Delivered-To: cavexml-archive_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 6F3F215876 for <cavexml-outgoing_at_ethz.ch>; Tue, 16 Jul 2002 10:13:46 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id 45A2A14BA0; Tue, 16 Jul 2002 10:13:44 +0200 (CEST) Delivered-To: cavexml-loopcheck_at_ethz.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 1BA1C15876 for <cavexml-loopcheck_at_ethz.ch>; Tue, 16 Jul 2002 10:13:43 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id E589D8A97; Tue, 16 Jul 2002 10:13:40 +0200 (CEST) Delivered-To: cavexml_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 964E815876 for <cavexml_at_cartography.ch>; Tue, 16 Jul 2002 10:13:40 +0200 (CEST) Received: from relay1.melbpc.org.au (newglider.melbpc.org.au [203.12.152.9]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 03D2D8A76 for <cavexml_at_cartography.ch>; Tue, 16 Jul 2002 10:13:36 +0200 (CEST) Received: from localhost.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by relay1.melbpc.org.au (8.12.3/8.11.6) with ESMTP id g6G7xeQO007010 for <cavexml_at_cartography.ch>; Tue, 16 Jul 2002 17:59:40 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Tue, 16 Jul 2002 17:50:27 +1000 From: Peter MATTHEWS <matthews_at_melbpc.org.au> In-Reply-To: <20020713183223.E8A337D84_at_karmail.ethz.ch> Message-Id: <5.1.0.14.1.20020716152043.01d72c20@popa.melbpc.org.au> Received: from relay1.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by localhost.melbpc.org.au (AvMailGate-2.0.0.6) id 06791-2CAEB6DE; Tue, 16 Jul 2002 17:59:28 +1000 Received: from peter.melbpc.org.au (a2-44.melbpc.org.au [203.12.157.44]) by relay1.melbpc.org.au (8.12.3/8.11.6) with ESMTP id g6G7xOsm006720 for <cavexml_at_cartography.ch>; Tue, 16 Jul 2002 17:59:26 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) Subject: Re: ERD based on? To: cavexml_at_cartography.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-Sender: matthews_at_popa.melbpc.org.au X-Loop: cavexml Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
At 14:23 13-07-02 -0400, Richard Knapp wrote:
>I have been reading through the item 6.1 and have an objection.
>
>I whole heartedly disagree things should start with a relational
>database approach then move to other structures. CaveXML is not
>relational in context; it is closer to object based. Starting from a
>relational then moving to XML is not very easy.
>
>Any work done on CaveXML should be done to work towards generating
>and storing data in XML format, not RDBMS.
Richard I don't think there is actually anything to worry about there.
Maybe I could have worded it better - there was a lot of stuff to get out
so bits of it are sure to need clarification or adjustment.
When I said "using relational methods" I did not mean diverting off and
working out how to set up a detailed relational db, but rather, using a
tool which is commonly used when designing relational systems, namely the
entity-relationship diagram (ERD), or at least my cut-down approximation of
one. This "ERD" is actually just a logical model of a real-world data
system, and is quite independent of how you might actually implement a
physical database to store the data, i.e. it's just as relevant when you
use XML for the physical implementation as when you use an RDBMS. The
diagram shown is still just the first draft of course - something to enable
us to start discussing the model.
What we are actually trying to get to is definitively finding out all the
data fields we need to consider when we design the XML part, and, just as
importantly, how they all fit into the overall data structure, e.g. what is
part of what. To do this we need to find out all the entities (real-world
things) which are involved in a cave survey and how they relate to each
other, because the fields which we are looking for are in fact the
properties of these same entities, e.g. the field "distance" is a property
of the entity "shot". (Whether it's an XML "element" or an XML "attribute"
is another question of course, but we don't need to worry about that until
we come to do the XML design.)
The reason I have recommended using an ERD for this first phase is because
it enables us to visualise and discuss just the entities and their
relationships with each other without also having the complication of XML
formatting and structure to think about. It will be hard enough as it is.
The data and its structure exists whether we come along with XML or not, so
it is very reasonable to discuss and document it on its own merits without
worrying about XML at all. Then, after we have got all the entities, fields
and their inter-relationships sorted out we can concentrate on how we are
going to express that validly in XML. We'll then be sure what data fields
there are that we have to include, and we'll know how they all fit
together, so the XML part should then be relatively straightforward. :-)
What do others think? Is this a reasonable approach to enable us to
actually start moving forward?
Peter
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:00 CEST