From: martinl_at_talk21.com
Date: Tue Feb 13 2001 - 19:50:26 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id TAA00386 for cavexml-outgoing; Tue, 13 Feb 2001 19:50:21 +0100 Received: from t21mta02-app.talk21.com (mta02.talk21.com [62.172.192.41]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA00382 for <cavexml_at_cartography.ch>; Tue, 13 Feb 2001 19:50:20 +0100 From: martinl_at_talk21.com Received: from t21mtaV-lrs ([10.216.84.13]) by t21mta02-app.talk21.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20010213184652.HJOD19514.t21mta02-app.talk21.com_at_t21mtaV-lrs>; Tue, 13 Feb 2001 18:46:52 +0000 X-Mailer: talk21 v1.17 - http://www.talk21.com To: cavexml_at_cartography.ch, cavexml_at_cartography.ch X-Talk21Ref: none Date: Tue, 13 Feb 2001 18:50:26 GMT Subject: Re: defaulting units for measurements Content-type: text/plain; charset="ISO-8859-1" Message-Id: <20010213184652.HJOD19514.t21mta02-app.talk21.com@t21mtaV-lrs> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by karto.ethz.ch id TAA00383 Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Richard Knapp suggested a sample XML fragment using IDs and IDREFs. I think he
misunderstood their usage and, below, give a corrected version of what I think he
intended. I also point a
problem with IDs, and to the related concept of XSL keys.
> > Sounding a little like keys into a table in a database, very good conclusion. A stations's
> key would only exist for that particular version of a CaveXML file. Changing the data
> after reading it and then re-writing it would of course generate a new and probably
> different set of station keys.
>
> Would it be better to generate keys for each station or each survey? I'm thinking
> specifically of the way Survex handles data. If the key to each station was changed
> each time the data was saved, would this change the way the links between surveys
> would have to be handled?
>
>There is a single station id, which all aliased or equated stations are replaced with.
>This is done in the background, the shot with the aliased or equated station would be an
>index to a third table, containing all equated stations and their lookup to the master
>station ids.
>
>So something similar to:
>
<survey>
> <shot>
> <from IDREF="000000001"/>
> <to IDREF="00000000A"/>
> </shot>
> <shot>
> <from IDREF="00000000A"/>
> <to IDREF="00000000B"/>
> </shot>
</survey>
<station_index>
> <station ID="000000001" name="A1"/>
> <station ID="00000000A" name="B1"/>
> <station ID="00000000B" name="B2"/>
</station_index>
>
>or something like that?
>
>Is that correct? If so, wouldn't I be pretty much required to use a special program to handle that?
>Or could I just use any XML editor? How much can be specified in the DTD/Schema to make this
>work?
>
1 ID and IDREF are attribute types, not attribute names (you can give an attribute of type ID the name ID
as well but this is not required; I use 'name' in the station element below, but you could use 'ID' instead) so your example should look more like:
<survey>
<shot>
<from station="A1"/>
<to station="B1"/>
</shot>
<shot>
<from station="B1"/>
<to station="B2"/>
</shot>
</survey>
<station_index>
<station name="A1"/>
<station name="B1"/>
<station name="B2"/>
</station_index>
where the DTD or Schema identify attribute station of the from and to elements as of type IDREF
and attribute name of element station as of type ID.
A corresponding DTD would include:
<!DOCTYPE survey [
...
<!ELEMENT from >
<!ATTLIST from station IDREF >
<!ELEMENT to >
<!ATTLIST to station IDREF >
<!ELEMENT station >
<!ATTLIST station name ID >
]>
An XML Schema might include something like:
<complexType name="shot" >
<element name="from" type="stationType" />
<element name="to" type="stationType" />
</complexType>
<simpleType name="stationType" type="IDREF" />
<element name="station" type="ID" />
This is a much more 'natural' form than Richard was envisaging, but an XML Editor using a DTD or Schema
should enforce
uniqueness on the values of attributes of type ID (but might not).
The interpretation of a value as an ID is done on parsing when a non-unique id might be
signalled as an error, or possibly ignored.
XPath has an id() function which selects an element by its ID attribute value.
2 There is a problem identified long
ago by Mike Lake in that IDs should be valid XML Names which means (amongst other things)
that they MUST begin with a letter; this example is ok, but all those surveys with integer
station numbers (as recently suggested) would be invalid. (Of course, you could get round
this with prefixes ...)
3 XSLT has a key() function which selects elements according to their content once the <xsl:key>
element has been used to define values for use in
subsequent processing. The difference from IDs is that keys (as used here) do not have to be unique.
See an example of it in use at:
http://website.lineone.net/~martinla/GOG/svg/kml2svgP.xsl
or follow 2D drawings or XSLT stylesheet links from
http://www.laverty.freeserve.co.uk/XML/KML.htm
Hope this helps...
Martin L
--------------------
talk21 your FREE portable and private address on the net at http://www.talk21.com
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET