XML

[Wookey]

On Wed 03 May, Michael Lake wrote:

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

I agree this is a very sensible direction to go in, it embodies many of
the good concepts worked out at the (not yet published - my fault :-( )
UIS congress survey meet.

I am now producing docs in SGML Docbook so I can probably usefully help
with this work (although I'm not yet clear what the differences between
SGML and XML are - they seem to be nearly identical).

> A cave browser using this [XML] 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.

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.

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

Some things are probably hard to categorise one way or the other. But if
we agree on this principle I'm sure we can muddle through.


[re: outputting depth labels

> What did you want to do exactly?

I am still producing survys on pieces of paper at the moment (RSI and
current state of technology are both preventing me computerizing the
whole process at the moment). Each survey needs a set of depth labels for
ends of caves/bottoms of significant areas) to stick on (these make it
much easier to relate plan and elevation of an unfamiliar cave).
Producing these is currently highly labour-intensive, especially when you
have to keep doing it for the same cave, but they change with new survey
loops, and new entrances. If my survey software could generate it for me,
that woule be one tedious job improved.

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

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

eg on my psion for expedition use the HTML/JPEG/GIF info on the caves
takes up 25Mb. The survey data takes up 700K. I don't see a problem in
expanding that a little more in exchange for more functionality. I don't
yet know how big the survex EPOC exectuables will be - that's on my job
list (and not getting any closer to the top right now :-(.

Wnough waffle for now, but I'd just like to say we have some good ideas
and people here - it's nice to see the open-source thing working the way
it is supposed to. I expect we'll get some really neat survey software
eventually.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel (00 44) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/