From: devinkouts_at_earthlink.net
Date: Tue Jan 23 2001 - 19:58:52 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id TAA03826 for cavexml-outgoing; Tue, 23 Jan 2001 19:56:46 +0100 Received: from [209.70.170.131] (brick.cist.saic.com [209.70.170.131]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id TAA03822 for <cavexml_at_cartography.ch>; Tue, 23 Jan 2001 19:56:44 +0100 From: devinkouts_at_earthlink.net Received: from cist.saic.com by [209.70.170.131] via smtpd (for karto.ethz.ch [129.132.127.159]) with SMTP; 23 Jan 2001 18:57:00 UT Received: from earthlink.net (unverified [10.43.39.246]) by exmail.cist.saic.com (EMWAC SMTPRS 0.83) with SMTP id <B0000710506_at_exmail.cist.saic.com>; Tue, 23 Jan 2001 13:57:58 -0500 Message-ID: <3A6DD46C.5C6B291E@earthlink.net> Date: Tue, 23 Jan 2001 13:58:52 -0500 X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Re: LRUD: 'From' or 'To' ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk
That's a good question Richard, and one that I've been looking forward
to discussing on this list.
I am of the opinion that a shot is a collection of data. And that those
data themselves may be collections of other data. Taken collectively
they give you all the information that is available about a shot. I
don't think it's possible to describe all the potential data elements
that may eventually become part of a "shot" (e.g. if survey techniques
improve) so maximizing the ability to expand a shot's definition seems
like a good idea.
While there is no right or wrong way with regard to how you represent
data in XML, either as Elements or Attributes, there are definitely some
consequences of using one versus the other. XML Elements are designed to
be organized in a nested fashion. This ability means limitless amounts
of data can be organized, searched and addressed in an easily navigable
hierarchical structure. Each Element can have Attributes, as many as the
author wishes, but Attributes can not be nested or organized
hierarchically. I.e. Attributes can not have children. Instead
Attributes are merely appended one after the other to the Element they
modify. The consequence of this is a very "flat" collection of data, and
Attributes (which are basically sub-Elements of a super Element) are
themselves very difficult to assign Attributes to.
In this example, for instance:
<SHOT FROM="88" TO="88a" AZIM="7.18" ELEV="10" DIST="+44.5" >
This shot was a bit difficult.</SHOT>
At least two of the attributes are ambiguous enough that they need
further information in order for them to be interpreted correctly.
Specifically, DIST="+44.5" does not tell me unit of measure in which the
distance was recorded. Was it feet, meters, furlongs? The ELEV="10"
attribute is similar. By looking at this record one can't determine if
this is ten degrees, or a ten percent grade (%), or some other unit of
measure (e.g. depth change in a cave dive survey).
A UNITS attribute could be added to this SHOT to indicate the
appropriate unit of measure, but there are at least two types of units
to account for, so two different UNIT attributes would be needed.
Something like ELEVUNIT and DISTUNIT.
The result would be something like this:
<SHOT FROM="88" TO="88a" AZIM="7.18" ELEV="10" DIST="+44.5"
ELEVUNIT="degrees" DISTUNIT="meters">
This shot was a bit difficult.</SHOT>
Now you begin to see how long and flat a simple SHOT record starts to
become.
In reality it is more likely that various UNITS would have been
specified at a global level, i.e. before the first SHOT, in something
like a SURVEY header area. But I've recently come to realize that even
this is an incomplete solution. While it's a useful technique to declare
values globally that could/should be applied as defaults to the children
(SHOT) Elements, it's also necessary to have an "override" capability
such that the SHOT child of a SURVEY can override the global UNITS if
need be. For instance, if your survey suddenly switches from
decimal-feet to feet and inches (not an infrequent blunder in some U.S.
surveys), you'll need to indicate this at each SHOT where it occurs.
There are other drawbacks to the use of Attributes, including the
reliance on inferred knowledge in the example above. I.e., FROM="88" is
recognizeable to a surveyor as a survey station, but we must infer this
from our experience as surveyors. On the other hand
<StationName>88</StationName>, leaves no doubt as to what "88" really
is. The FROM relationship can be recorded elsewhere in the XML file,
probably subordinate to the <SHOT> but parent to the <StationName>.
A rule of thumb I've read in my XML research is this: Use Elements to
enclose data to the greatest degree possible. Use Attributes to modify
Elements in those cases where the data is highly static. For example:
<Compass serialNumber="123456"/>
In a nutshell, extensive lists of Attributes describing a single Element
are indicative of data that lends itself well to a nested structure.
Devin Kouts
Caver
Systems Engineer
www.psc-cavers.org
-----Original Message-----
From: owner-cavexml_at_karto.baug.ethz.ch
[mailto:owner-cavexml_at_karto.baug.ethz.ch]On Behalf Of Richard Knapp
Sent: Tuesday, January 23, 2001 7:36 AM
To: cavexml_at_cartography.ch
Subject: Re: LRUD: 'From' or 'To' ?
>This was what I came up with early last year. The idea is taken from
geology.
>
><SHOT FROM="88" TO="88a" AZIM="7.18" ELEV="10" DIST="+44.5" >
> This shot was a bit difficult.</SHOT>
Interesting construction. A question: is a shot made up of the data or
are they attributes of the
shot? ie is a shot aggregation or just attributes?
-- Devin Kouts
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:52 CET