From: Paul & Eleanor (goodhill_at_xmission.com)
Date: Fri Feb 16 2001 - 06:47:02 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id GAA17537 for cavexml-outgoing; Fri, 16 Feb 2001 06:43:18 +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 GAA17533 for <cavexml_at_cartography.ch>; Fri, 16 Feb 2001 06:43:17 +0100 Received: from slc7.modem.xmission.com ([166.70.9.7] helo=xmission.com) by mail.xmission.com with esmtp (Exim 3.12 #1) id 14Tdft-0006HY-00 for cavexml_at_cartography.ch; Thu, 15 Feb 2001 22:43:22 -0700 Message-ID: <3A8CBED6.A8BB28EB@xmission.com> Date: Thu, 15 Feb 2001 22:47:02 -0700 From: Paul & Eleanor <goodhill_at_xmission.com> X-Mailer: Mozilla 4.75 [en] (Win98; U) 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> <3A8BDDB8.1070106_at_aic.nrl.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Ralph Hartley wrote:
> How hard are you willing to work to preserve data you don't care about?
Not very, if the data is already in the full caveXML, I'll just leave
it there.
> How hard are you willing to work to remove data you don't care about?
I was thinking of extracting only what I wanted.
> > 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.
Hopefully the caveXML file with extra stuff serves that purpose. I
guess
we are in agreement on that point.
> 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.
That is assuming he isn't just using caveXML to transport data. He may
use something else to store it.
Another choice is I can build something that merges just his subset
and my subset.
> >
> >> 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.
This is the problem of the person who has the one-way solution. When
the
are not in 'the loop', they might feel the pressure to complete circuit.
> 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.
Sure, I totally agree, but those who don't make the round trip can
just watch you.
> 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).
Sounds like a fair approach. I hope everyone follows such an approach,
it is just not practical to expect everyone to implement a roundtrip
solution, but I wouldn't care if there are one-way solutions that exist,
they just won't be as useful as a two-way implementation.
Good discussion as usual,
-Paul
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET