XML: was Bedding planes, rose diagrams and bug fix

[Michael Lake]

Hi All,

This is great discussion. There are several new ideas here in just one
day!

Wookey wrote:
> 
> On Tue 02 May, Phil Underwood wrote:
> > On Tue, 02 May 2000, you wrote:
> > >
> > >1) display indicator of entrances. (hmm, that's not really analysis is
> > >it, but it would be _really_ useful)
> > >
> > But we need then to have a command like *entrance <station> to define an
> > entrance, and this needs to be transferred to the 3dx file somehow.
> 
> Indeed. This would be an attribute of the entrance station. sytanx might
> perhaps be
> *attribute entrance <station>
> I've posted a couple of times to this list about my ideas for attributes,
> in an attempt to get a consenesus to make it worth implemntning
> something, but got bugger all response. I suppose that means no-one
> violently objected. But I was kind of hoping someone else would actually
> get enthused an implement it :-)

Adding more 'tags' *attribute and thinking of "Attributes" for things in
a cave survey means that I really do need to put in a plug here for my
CaveSurvey XML Language. I have a document type definition (DTD) and
examples of two XML languages for caving on my web site that would help,
either in two ways; 

1. by providing folks like you with ideas of what to include a a cave
survey data format
2. by using CaveSurveyXML and CaveMapXML in your programs.

Have a look at http://www.science.uts.edu.au/~mikel/ and follow the
CaveScript links. The CaveScript Homepage directly is
http://www.science.uts.edu.au/~mikel/cavescript/
Go to the 'Documentation-on-line' and click on the 'example2.xml'.

It's under the heading "Utility Programs - Survex to/from XML",
Examples.

Using this data format I would add an attribute to the STN tags like
this:
<STN NAME="85" TYPE="ent">Cusp (lower one) of rock at base of 1st
drop.</STN>

A cave browser using this file (such beasts don't exist yet) would
recognise the Station 85 as an "Entrance" and render it in someway -
probably via a style sheet.

> > If you *fix all the entrances, I'd be able to make chasm display marks next
> > to fixed stations.
> > Any ideas what symbol you'd want to use here - what about #p161 instead of
> > \p161, next to a cross marking the location?

This brings me to another point. I think that many of these enhancement
to the Survex data file pertain to how a cave survey should be viewed
rather than to how it should be processed. The Survex data format at
present describes to a data reduction engine how to process the data. I
think that how its viewed should  be separate. Like a word processing
dooc and its styles or a HTML doc with its structure + CSS.

> A flexible mechanism for connecting symbols/colours to attributes is
> definately in order, with some sensible defaults.
Same thing. Use a CaveSurveyXML/CaveMapXML format with a 'style sheet'
where the user can specify how they want the symbols displayed. The
CaveMap XML just says that this station is 'fixed' this one is an
'entrance' this is a major relocatable point etc.

> > >Maybe aven already has these? Oh how I wish I could compile all these new
> > >versions :-(... [last attempt told me that gtk was missing a load of Xlib
> > >headers which presumably means I need X-devel package(s). It's such a long
> > >CD/download chain to get anywhere if you don't start from the right

I have the same prob on my Alpha at home. Linux is changing so fast that
I am behind in all the libs and I can't compile chasm yet - will do so
hopefuly this month.

> At the moment I have to loko at the survey and write down some suitbale
> points, then manually go through the POS file fishing out the numbers and
> rounding them and typing them into a TeX file. Next time we find another
> entrance I have to do them all again.
> 
> > I'd prefer to output plain ASCII (maybe tab-delimited)- much more portable,
> > and you can cut and paste more happily into other apps. And of course,
> > ASCII is easy, and I don't understand TeX too well.

I know LaTex reasonably and its what I used to do a 1st proof-of-concept
for my CaveMapper program but I decided to churn out straight Postscript
instead. Still some scripts for doing this might be useful for some.
What did you want to do exactly?

AS for XML: A common format for the storage and exchange of cave survey
data (like what Doug Dotson's HTO attempted to do a few years ago) would
be valuable. The way I see my XML fitting in with Survex is that Survex
data format stays very much as a minimal, fast, simple format for data
processing. CaveSurvey XML files with lots of info on the survey can be
converted easily into Survex format for cavern to process - most of the
Survey info is just stripped out and Survex format is output. Keep
Survex simple and fast. 

Mike

--------------------------------------------------------------------
Michael Lake
University of Technology, Sydney
Email: mailto:Mike.Lake@uts.edu.au Ph: 02 9514 1724 Fx: 02 9514 1628 
URL: http://www.science.uts.edu.au/~mikel
Linux enthusiast, active caver and interested in anything technical.
--------------------------------------------------------------------