From: Paul & Eleanor (goodhill_at_xmission.com)
Date: Thu Jan 18 2001 - 07:04:03 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id HAA06549 for cavexml-outgoing; Thu, 18 Jan 2001 07:01:05 +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 HAA06545 for <cavexml_at_cartography.ch>; Thu, 18 Jan 2001 07:01:04 +0100 Received: from slc815.modem.xmission.com ([166.70.6.53] helo=xmission.com) by mail.xmission.com with esmtp (Exim 3.12 #1) id 14J887-0003uz-00 for cavexml_at_cartography.ch; Wed, 17 Jan 2001 23:01:04 -0700 Message-ID: <3A668753.7B08F04D@xmission.com> Date: Wed, 17 Jan 2001 23:04:03 -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: CDFO: Raw Data and XML References: <3A6464E6.58B17C34_at_earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk
devinkouts_at_earthlink.net wrote:
>Existing standards should be used to determine the type
Here, here!
Can anyone point us all at some good examples of 'prior art'?
Note, correct me if I'm wrong but isn't any tag the is defined
to contain CDATA, could contain unknown tags and normal XML
parsing would be able to handle the data.
> Never build what you can borrow.
Yes, yes! That is the basic idea of using XML, I hope we can carry
the idea forward.
> There is of course a down side to including the original in processed
> data. The files could grow exponentially. This can happen when each step
> in the process adds its own copy of everything that came before. You can
> end up with an astronomical number of copies of the same thing. Having a
> big disk drive doesn't help here, a billion gigabyte disk will still end
> up full. Having lots of capacity just hides the problem untill it is to
> late to fix it.
Good point. At some point, the guy (or girl) generating a fully
corrected digitized polygon modeled tourable cave passage, has just
got to toss the "survey page image" text, original XML form of the data,
corrected survey lines and
the cover page for every survey and ... and let that be in some other
file.
And the guy who is generating a cave with trip reports linked to
the surveys should throw away 30 polygons per survey shot the
other guy generated.
Okay my examples are way out there, but if we could support both
folks it would be beautiful. But can we?
> Some restraint in USING the ability to include files is called for. A
> good place to start would be a rule like "never include the same data
> more than once in the same file".
There is an area for semantic definition! I'd go with that rule so far.
-Paul
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:52 CET