Re: Required ability of software? none

New Message Reply About this list Date view Thread view Subject view Author view

From: Roger Schuster (roger_at_r-schuster.de)
Date: Mon Feb 12 2001 - 19:36:19 CET 

Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id UAA09836 for cavexml-outgoing; Mon, 12 Feb 2001 20:39:13 +0100
Received: from mail.arcor-ip.de (mail-ffm-p.arcor-ip.de [145.253.2.10]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA09831 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 20:39:12 +0100
Received: from r-schuster.de (145.253.168.172) by mail.arcor-ip.de; 12 Feb 2001 20:38:41 +0100
Received: from localhost (roger_at_localhost) by r-schuster.de (8.11.0/8.11.0) with ESMTP id f1CIaJ301548 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 19:36:19 +0100
Date: Mon, 12 Feb 2001 19:36:19 +0100 (CET)
From: Roger Schuster <roger_at_r-schuster.de>
To: <cavexml_at_cartography.ch>
Subject: Re: Required ability of software? none
In-Reply-To: <3A856169.5B5C564E_at_xmission.com>
Message-ID: <Pine.LNX.4.30.0102121858320.1520-100000@r-schuster.de>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cavexml_at_karto.baug.ethz.ch
Precedence: bulk
Reply-To: cavexml_at_cartography.ch

On Sat, 10 Feb 2001, Paul & Eleanor wrote:

Hello,

> Please let's not force others to care about things that aren't important
> to them.
>
> It depends on software. If an author wants his software to be an
> authoritative database for anything anyone throws at it, then yes, I
> suppose the author must "expand his native file format in a way that it
> can keep the additional info even if the software doesn't work with it.",
> but consider the following examples.

You haven't understand what I'm talking about. The author of cave surveying
software must not expand his program in a way that it can *use* (in the
sense of processing and displaying) any kind of input but he must take care
of not loosing information.

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.

Roger 

-- 
Roger Schuster  eMail    roger_at_r-schuster.de
                Cavepage http://www.karst.net
The very first "Point and Click" technology - a Smith & Wesson!

New Message Reply About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET