From: Ralph Hartley (hartley_at_aic.nrl.navy.mil)
Date: Mon Feb 12 2001 - 21:33:56 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA10094 for cavexml-outgoing; Mon, 12 Feb 2001 21:30:43 +0100 Received: from sun0.aic.nrl.navy.mil (sun0.aic.nrl.navy.mil [132.250.84.10]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA10090 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 21:30:42 +0100 Received: from aic.nrl.navy.mil (pc31.aic.nrl.navy.mil [132.250.84.181]) by sun0.aic.nrl.navy.mil (8.9.3+Sun/8.9.3) with ESMTP id PAA08051 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 15:30:45 -0500 (EST) Message-ID: <3A8848B4.9020704@aic.nrl.navy.mil> Date: Mon, 12 Feb 2001 15:33:56 -0500 From: Ralph Hartley <hartley_at_aic.nrl.navy.mil> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20010124 X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Re: Required ability of software? none References: <Pine.LNX.4.30.0102121858320.1520-100000_at_r-schuster.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Roger Schuster wrote:
> If somebody passes CaveXML data to you with some type of information (e.g.
> freely placed cross sections) your program doesn't actually use (e.g because
> your program uses only LRUD located at the stations) you may throw away this
> additional info. No problem for you and your software. But if you write the
> data back to CaveXML in this case you have lost some of the original info
> (the cross sections between stations).
>
> This is the problem with the existing import and export filters of caving
> software. Each converter re-organizes the data (that's necessary of course)
> but it also skips and throws data it doesn't work with. This data is lost
> forever.
>
> Software which is CaveXML conform must *read* in any kind of information and
> keep the actually not needed data in a kind of meta information. If the user
> exports his processed data to CaveXML the software must also write the meta
> data back. Software must read *and* write data without loss of information.
> "One-way tickets" must be strictly avoided.
>
> Because of this thoughts we should keep CaveXML as simple as possible. A
> working sub-set of already existing file formats is much better than a
> super-set which will loose info here and there.
This is part of the reason for using something like XML. Given widely
available tools for reading and writing XML, there is no reason a
program should ever lose information just because it doesn't understand
it. The only restriction is that a conversion program that takes CaveXML
and produces (for example) CMAP input needs to keep track of enough
information about the translation (what cmap station names correspond to
what stations etc.) to edit the CaveXML file to match an edited version
of the cmap file, some restrictions on editing the cmap file (don't
delete generated comments) might be ok. This is more important for
programs (unlike cmap) that include their own editor. It would also be
nice to export cmap output into a form other programs could use.
It does not need to do anything at all with elements or attributes that
contain data cmap doesn't know or care about, except to transmit them.
In other words it should treat them as comments.
As long as unused data is preserved in this way, it really doesn't
matter how complex CaveXML is. Without the ability to ignore, but
transmit, unused data, there is no way to make an interchange language,
because some programs will REQUIRE information that other programs FORBID.
So from the same consideration, I come to the opposite conclusion: The
format must not exclude anything that any program needs. If at least two
programs use the same data, there should be a standard way to share it.
However we don't have to completely define everything now. It is only
important that basic structure we define now doesn't paint us into a
corner latter.
Ralph Hartley
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET