XML: was Bedding planes, rose diagrams and bug fix

[John Halleck]

On Wed, 3 May 2000, Michael Lake wrote:

> [...]

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

  I was about to make a post that discussed how strangly like the
  early XML discussions this was...

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

  Wow, I'm impressed...  You've put a lot of work into it, and given it
  a goodly amount of carefull thought to it.

  There are things I'd like to see, and didn't, in the area of data
  concerning survey adjustment.  But I suspect that that is not of
  general interest, so I'll take it up in private email.

  What you have looks good, and usable if one has something that
  can deal with XML as a front end.

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

  Not a bad Idea.
 
> > > 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.

  Years and years ago, we annotated the Little Brush Creek Cave Data
  with  (Back in the days of Fortran) tags like:
     =Start Name "foobar"
     =End   Name "foobar"
  with the hope of someday being able to give some program commands like:
     Display Name "Foobar" and Name "Back Section" minus Level Lower

  (While we annotated the data, we never wrote the code... *sigh*)

  I'd like to see someone do something of that sort now with XML and
  related tools. 
 
> [...]
> 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. 

  I agree, for what it is worth.

> 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.
> --------------------------------------------------------------------
> 
> 
> -- 
> Survex http://lists.tartarus.org/mailman/listinfo/survex
>