XML

[Michael Lake]

Wookey wrote:
> I use the jade parser to parse SGML here. I wonder if it can do XML too?
> There must be loads of XML developments out there that we could use bits
> of for our purposes.

There is a lot of stuff but much of it is still alpha or beta and its
changing so fast. I'm staying abck tonight to check out gnome-xml that
David Doolin suggested.

> > 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.
> 
> Yes, and Olly agrees. So do I, I think :-). However the 'entrance'
> example is not a good one in theis context. Whether a poiint defines the
> entrance is a feature of the data, not a feature of how it is displayed.
> Thus I think it is valid (important, even) to put it in the survex data
> file. Other information like how to fold extended elevations, preferred
> scales and plots, font sizes for labels etc is clearly 'stylesheet' info.

Agree. It is part of the survey information collected at he time. I have
given it some thought and intend to include it in the CaveSurveyDTD as
an attribute of a Station (STN) element. Prob something like <STN
NAME="34" TYPE="entrance">

> I am still producing survys on pieces of paper at the moment (RSI and
> current state of technology are both preventing me computerizing the
....Each survey needs a set of depth labels for
...If my survey software could generate it for me,
> that woule be one tedious job improved.

Seems a useful thing for some caves. I'll add this to my todo list for
my script that outputs Postscript cave maps.

> > 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.

> I have some sympathy with this concept but I am not convinced that that
> means we shouoldn't add anything to the the survex format. It's going to
> be a while before we have something that processes caveXML directly, and
> in the meantime I need entrances on my screen/paper plots right now :-)
....
> Survex files already have quite a lot of fluff in them in textual form
> (surveyors, dates, inst info, calibrations LRUDs).
> Structuring some of that fluff so that the software can use it will
> hardly increase the file size at all. eg it's really very naff that

Oh yes. I see what you mean. Survex files are still quite small. 

> Survex doesn't understand dates - and that makes it difficult to prepare
> a series of plots by date showing annual exploration, for example.

Thats why I have three different forms of <DATE> element in my XML
format: Survey date, Last modification date and Last access date.
 
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.
--------------------------------------------------------------------