From: Michael Lake (mikel_at_speleonics.com.au)
Date: Wed Jan 24 2001 - 10:41:22 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id MAA08177 for cavexml-outgoing; Wed, 24 Jan 2001 12:51:11 +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 MAA08173 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 12:51:10 +0100 Received: from speleonics.com.au (mikel_at_dm1-23.triode.net.au [203.63.34.24]) by iggy.triode.net.au (8.11.1/8.10.1) with ESMTP id f0OBpOY29189 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 22:51:24 +1100 Message-ID: <3A6EA342.628CEB2D@speleonics.com.au> Date: Wed, 24 Jan 2001 20:41:22 +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: LRUD: 'From' or 'To' ? References: <3A6DD46C.5C6B291E_at_earthlink.net> 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
Richard wrote:
> 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?
Thats what we have to decide- and get it right! Its not clearcut at all.
devinkouts_at_earthlink.net wrote:
> 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
.....
> 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.
......
> 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?
In my DTD I have:
<!ATTLIST TAPE
%instrument_id;
%used;
%zero_correct;
%scale_correct;
%accuracy;
UNITS (METRES | FEET | YARDS ) "METRES"
>
I just did not put in that example all the things one might have.
> 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>
I don't think having different UNIT TYPES is good. What I did in my DTD was to have the
same attribute named UNITS but its context ie what element it was an attribute of
determined its behavior. That way when we add new instrument elements (some new device) we
just have UNITS again and don't have to come up with fooUNIT. This is how its done with
the COMPASS and CLINO. Notice its the same as TAPE. Keeps things simple. Learn one
attribute UNITS and it applies the same to all other instrument ELEMENTS.
<!ATTLIST COMPASS
%instrument_id;
%used;
%zero_correct;
%scale_correct;
%accuracy;
UNITS (DEG | DEGREES | GRADS | MILS | MINUTES) "DEGREES"
>
<!ATTLIST CLINOMETER
%instrument_id;
%used;
%zero_correct;
%scale_correct;
%accuracy;
UNITS (DEG | DEGREES | GRADS | MILS | PERCENT | PERCENTAGE) "DEGREES"
>
> Now you begin to see how long and flat a simple SHOT record starts to
> become.
However in hindsight I would prob have my comments in a COMMENT element. That way they can
be extracted easier and also the COMMENT element ca then have its own attributes if need
be.
> 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.
Global eeeeekkkkkkk !!!!!!
> 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.
Once declared in INSTRUMENTS it would be read by a parser into an applications
memory/variable and can be in effect until another INSTRUMENT element chnages it.
We don't want to indicate it for every shot. We dont want eg. survex files when turned
into XML files to be as big as M$ Word files :-)
> 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.
The things reading XML files will prob be programs. They will understand.
> 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>.
The XML data file can get very verbose if we scorn attributes.
> 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.
The above does seem sensible. Well I would think that TAPE UNITS=metres is quite static.
Even if the tape has an inches/feet scale surveyors in Aust dont use that. The units
rarely change. Same with compass units=degrees we dont often change to grads. So I can
argue that those attributes are relatively static so should be attributes.
This conversation is now really starting to get us thinking well.
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 : Wed Feb 14 2001 - 00:03:52 CET