From: P A Hill & E V Goodall (goodhill_at_xmission.com)
Date: Wed Jul 10 2002 - 00:40:01 CEST
Return-Path: <owner-cavexml-outgoing_at_ethz.ch> Delivered-To: cavexml-archive_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 0268315840 for <cavexml-outgoing_at_ethz.ch>; Wed, 10 Jul 2002 01:02:47 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id D20D315804; Wed, 10 Jul 2002 01:02:44 +0200 (CEST) Delivered-To: cavexml-loopcheck_at_ethz.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id A0D9D15840 for <cavexml-loopcheck_at_ethz.ch>; Wed, 10 Jul 2002 01:02:43 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id 81E1814AB3; Wed, 10 Jul 2002 01:02:41 +0200 (CEST) Delivered-To: cavexml_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 3417315840 for <cavexml_at_cartography.ch>; Wed, 10 Jul 2002 01:02:41 +0200 (CEST) Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 90490148DE for <cavexml_at_cartography.ch>; Wed, 10 Jul 2002 01:02:38 +0200 (CEST) Received: from mail by mgr1.xmission.com with spam-scanned (Exim 3.35 #1) id 17S3sO-0004Hk-00 for cavexml_at_cartography.ch; Tue, 09 Jul 2002 16:54:33 -0600 Received: from [198.60.22.200] (helo=mail.xmission.com) by mgr1.xmission.com with esmtp (Exim 3.35 #1) id 17S3aX-0006v8-00 for cavexml_at_cartography.ch; Tue, 09 Jul 2002 16:36:05 -0600 Received: from goodhill.dsl.xmission.com ([198.60.114.17] helo=xmission.com) by mail.xmission.com with esmtp (Exim 3.22 #1) id 17S3XS-0001ws-00 for cavexml_at_cartography.ch; Tue, 09 Jul 2002 16:32:54 -0600 Message-ID: <3D2B6641.9030101@xmission.com> Date: Tue, 09 Jul 2002 16:40:01 -0600 From: P A Hill & E V Goodall <goodhill_at_xmission.com> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us To: cavexml_at_cartography.ch Subject: Re: comments on the data model References: <20020709212537.046C614AE9_at_karmail.ethz.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=8.0 tests=none version=2.31 X-Spam-Level: X-Loop: cavexml Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
Richard Knapp wrote:
> Would this not be just reinventing what W3C is already working? Even though SVG is
> currently limited to 2-D representations, it could easily be eXtended to fit the needs of
> CaveXML. And if SVG is produced, then other programs besides cave specific ones will be
> able to use the data. To me, that would be better than trying to create yet another data
> format. (FWIW)
I read the previous posters comments as meaning.
1. original form in non CaveXML, either images, or in some foreign format,
(or appropriate links to same) for those who want to retain such for historical
reasons.
Note: I'd leave room for stuffing nearly anything in here, in a
mime-type like style of "If you understand what this tags attribute means,
you probably can figure out the content of the this block, otherwise
you are welcome to ignore it", but you might want to keep it for someone
who does understand it.
2. original form in CaveXML, retained for historical reasons if wanted.
This is just as it was first formed in CaveXML from either the
foriegn format, or directly from someone who typed it in.
3. cleaned up (final edit) form in CaveXML, the basis for lots of
processing with anything changed or added fleshed out, tagged and
otherwise modified.
4. processed form, i.e. still CaveXML data structures with room for
everything from text stories, to GIS information, cave inventory items,
cross sections, loop closure statistics, error matricies, contectivity
information etc. this is where all the weird stuff lives, even if
it didn't exist before.
If there is SVG as the format at this stage then we'd only have lots of vectors,
polygons and text. While there is some interesting ways to group and classify
lines, objects and text in SVG (which might make some useful prior art
for CaveXML), I don't see that this pahse 4 "processed version" of CaveXML as
SVD plus some extras. I see this Step 4 "processed" data more like CaveXML
occassionally using a polygon or line construct borrowed from SVG where an
equivalent exists and is needed (to describe a cross section, to define a room
etc.).
But on beyond "processed" maybe there is another form,
just like at the beginning we have a place to put any
pre-CaveXML form, at the other end of the processing model
there might be a level 5 data which would be something generated
from the CaveXML but it is in some other format. This is were
some neat SVG model, of simple box walls, or complex walls,
or a plan view, a stick figure, a cut away would live. This is
a place to put whatever some tool is capable generating from the
"processed" caveXML.
I'd expect all of the types of objects found in a type 5 tag
to be in some other format than CaveXML.
Just another 2.5 cents worth, but don't ask me if those are
cents of Euro, Canadian or USD.
-Paul
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:00 CEST