From: Ralph Hartley (hartley_at_aic.nrl.navy.mil)
Date: Thu Feb 15 2001 - 14:46:32 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id OAA13501 for cavexml-outgoing; Thu, 15 Feb 2001 14:43:14 +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 OAA13497 for <cavexml_at_cartography.ch>; Thu, 15 Feb 2001 14:43:13 +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 IAA23973 for <cavexml_at_cartography.ch>; Thu, 15 Feb 2001 08:43:16 -0500 (EST) Message-ID: <3A8BDDB8.1070106@aic.nrl.navy.mil> Date: Thu, 15 Feb 2001 08:46:32 -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> <3A8848B4.9020704_at_aic.nrl.navy.mil> <3A8A1BA7.7F781E6E_at_xmission.com> 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
Paul & Eleanor wrote:
>> Roger Schuster wrote:
>>
>>> "One-way tickets" must be strictly avoided.
>>
> What are you going to do? Send the thought police to my house when I
> "scratch" XYZs out of a caveXML and display using of them using
> some simple 3d viewer? Come on, your concerns are un-enforcable
> and meaningless.
No, would you like us to? We would have to charge extra for that! What
we *might* do is supply a free tool for reading and writing caveXML. If
it is the easiest way to read the file, and it preserves what we say
needs to be preserved (that's everything), you might have to go *way*
out of your way to scratch out XYZs. That would be very different from
the current situation where you have to do quite a bit of work to
*preserve* XYZs.
How hard are you willing to work to preserve data you don't care about?
How hard are you willing to work to remove data you don't care about? If
the answer to both questions is "not very", we (everyone) could win.
> If you don't want to loose data don't send it through anything that
> doesn't preserve what you want.
But first, make sure there *is* something that preserves what you want.
That is the goal of CaveXML.
> If you send data to a friend and the friend sends back less of your
> data,
> but with a few things of their own you can either deal with it,
> find a new friend, or tell them you won't send them data until
> they fix their software. There really are not other choices.
> The idea you could enforce what people could do with caveXML is
> not even worth the time defining limits.
There are other choices. You could help him fix his software. The best
time to do that is when designing the format and the tools that go with
it. That time is, of course, now.
>
>> 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.
>
> Solution? Keep the original.
That is not a solution! It doesn't allow data added in the new format to
be merged back in. A successful exchange format should allow a much more
"component" based approach to using programs. For example, I might want
to use the viewer from compass to look at the lineplot, but do loop
closures with some other program (some people consider compass's loop
closures broken, it doesn't matter for this discussion if that is true
or not), and then use my program to draw the map. And I never want to
know or care about what conversions are going on.
The implementation of a two way converter for a given program may
actually work by keeping a copy of the original, and keeping track of
enough correspondences between the original and converted files to merge
changes back. Most formats allow some sort of "comment". The original
and correspondence data could be included as comments in the converted
file. Deleting those comments would break the ability to convert back,
but that means you have to do work to cause a problem (you can always
mess things up if you try hard enough).
Ralph Hartley
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET