From: Paul & Eleanor (goodhill_at_xmission.com)
Date: Tue Jan 16 2001 - 08:06:42 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id IAA25768 for cavexml-outgoing; Tue, 16 Jan 2001 08:03:45 +0100 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA25764 for <cavexml_at_cartography.ch>; Tue, 16 Jan 2001 08:03:44 +0100 Received: from slc255.modem.xmission.com ([166.70.2.1] helo=xmission.com) by mail.xmission.com with esmtp (Exim 3.12 #1) id 14IQ9g-0008L7-00 for cavexml_at_cartography.ch; Tue, 16 Jan 2001 00:03:44 -0700 Message-ID: <3A63F302.66345F46@xmission.com> Date: Tue, 16 Jan 2001 00:06:42 -0700 From: Paul & Eleanor <goodhill_at_xmission.com> X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en CC: cavexml_at_cartography.ch Subject: Re: Past words References: <3A63D5F9.8060208_at_europa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk
Thanks for the ideas to work with:
This posting only addresses the general ideas, not specific tags
and tags structures.
Garry Petrie wrote:
> I believe Taco Van Ieperen
> No "call-back" routines or recursive descent compilers should
> be required parse the data.
Then we be screwed :-) One of the two (now three) standard ways
to hook Java and C++ to XML is via call backs (but only one
callback is actually required).
> 3. SIMPLE UNITS FORMAT. Another place where exchange format can wrong
> is to attempt to present the data every conceivable measurement
> units.
This sometimes conflicts with the idea of preserving what you already
have.
> A set of flags can be used to save the
> specifications for the original data format. As a long as enough
> digits of precision are saved, the original units can be easily
> restored once the data is transfered.
These flags would I believe have to retain not only units but precision
also.
> 4. FIXED ITEM ORDER.
XML avoids this problem.
> 6. EASY TO PARSE
As I said as this discussion got going over in caver mailing list:
The easiest code to write is that which is already written.
XML parsers of various forms are available from large a reputable
computer companies. Maybe this is a moot point.
> 7. EXTENSIBLE. Because it is impossible to anticipate all the needs
> of a cave surveyors, the format should be extensible.
Yes!
> The
> extensibility should be structured in such a way that extensions to
> the format do not result in chaos. For example, extension could be
> placed inside of "begin-end" pairs so that older translators can
> ignore new data items.
That would be a lot like XML.
> One final point. Our goal with this project is rather limited. What
> we are trying to develop here is file exchange format, not the
> ultimate format for saving or handling survey data. As a result, the
> format does not have to cover every conceivable situation. What we
> are try to create is a robust, and practical data exchange format.
Say what?
How can you exchange data unless you can represent it.
But, given that it is for exchange the form of these things does not
have
to efficient.
> begin=blocktype
> ... data goes here
> end=blocktype
Looking a lot like a relative of XML!
> G. UNCORRECTED DATA. All data is assumed to be uncorrected raw data.
I hope we can mark a section of data as one being corrected, one being
un-corrected, buut that would be a simple attribute.
> H. STATION NAME LENGTH. Station names are assumed to be 16 characters
> or less.
This seems a bit wimpy these days.
Well enough for now, I'll leave the particular tags for another day
or others.
-Paul
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:51 CET