spud beasts

[Julian Todd]

I've been following the discussion with a hint of despair.  
First it was all going to be so general that you wouldn't know 
what the content was.  And now you are talking about 
defining specific structures for the tiny amounts of data.  

The fact is it doesn't matter what form the data is stored in 
at all.  Whenever I have gotten hold of a cave data file 
in another format (Walls and Toporobot so far) I have been 
able to upgrade Tunnel to read it in half a days work.  
I'll be able to do the same with whatever you lot come up 
with, if anyone actually designs a cave in it.  

Why don't you consider sticking with the survex format 
and making the improvements to it I have outlined 
many times before (*exports, labels on the *calibrates, 
abolition of *include, *begin/*end, *equate and *units) ?  
All you are going to do is produce another data format 
with horrible flaws in it, in the same way survex had originally 
(with its \ operator, implicit equates and *prefix) which will 
take years to discover and probably won't get repaired 
in a hurry either.  I have proven that the survex format 
is extensible to 3D cross sections and cave drawing.  
So what, exactly, do you need another file type for?  Hmm?  
[Hint: you have to name a particular feature you can't 
have already now to make a justification]

The correct data format, in my opinion, is one that is 
as close a representation of the survey notes as possible.  
It's there that all the data comes in, and it's there where 
all the errors will be found.  The survex format already 
closely matches the written data.  Were we to get 
laser scanned data of cross sections, that data should 
remain in exactly its format.  If you can write a conversion 
unit from it into another format, you can write a reader for 
that format and do without your own invented format.  

Julian T.

PS What's wrong with Java apart from it's easy to write 
and you don't need to be a professional GTK programmer 
to do it?