From: Devin Kouts (devinkouts_at_earthlink.net)
Date: Sat Feb 17 2001 - 17:24:23 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id RAA25564 for cavexml-outgoing; Sat, 17 Feb 2001 17:16:58 +0100 Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA25560 for <cavexml_at_cartography.ch>; Sat, 17 Feb 2001 17:16:57 +0100 Received: from earthlink.net (sdn-ar-002varestP043.dialsprint.net [168.191.218.155]) by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id IAA06377 for <cavexml_at_cartography.ch>; Sat, 17 Feb 2001 08:17:04 -0800 (PST) Message-ID: <3A8EA5B7.5070404@earthlink.net> Date: Sat, 17 Feb 2001 11:24:23 -0500 From: Devin Kouts <devinkouts_at_earthlink.net> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: ko,en To: cavexml_at_cartography.ch Subject: Re: <DataFileVersion> References: <3A8A2C6C.85D33975_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
<DataFileVersion> was a recommendation from some of the software
developers I spoke with. And after witnessing some of the discussion
back and forth about what should or should not be part of CaveXML it may
prove a useful construct. <DataFileVersion> may not be the right way to
handle this, and you're suggestion to include it "in the opening tag" is
probably more appropriate, but the intent of the tag is:
A method of identifying which release of the CaveXML standard is in use
within this file. For instance version 1.0 of CaveXML may support a
specific set of basic data elements, where-as 2.0 supports an extended
set (e.g. complex cross sections).
The <DataFileVersion> tag may also be useful if we see a splintering in
the community with multiple XML "standards" as a result. In that
situation the tag might specify things like: CaveXML v1.0, or
OllyBettsXML v2.1, or AussieXML v0.9, etc...
<DataFileVersion> isn't meant to be the final answer, just a place
holder for something we should discuss and seriously consider including
in the CaveXML spec.
An alternative to this might be <CaveSurvey format="CaveXML" version="1.0">.
DSK
Paul & Eleanor wrote:
> Devin,
>
> I was looking at your web site.
> What would you really be able to do with this?
>
> If it is a version to indicate format of the file, it must b
> in the opening tag, otherwise what would happen if a new attribute
> was included in the opening tag? You wouldn't know it was allowed
> until after you'd closed the opening tag and then found out you were
> supposed to allow it...
>
> Maybe it indicates some internal phase, sub-system that the file has
> passed through. I supposed this has its uses, but only if there
> was some obvious linear sequence of such "phases". I'd rather want
> the ability to leave a "stamp" on the file, but include more than
> one such "stamp". No clue what this stamp would look like, but
> I wouldn't want "Model Complex Rooms" phase to exclude "build
> simple walls" phase or "Reduce loops" phase, because they might not
> be a set of ordered steps, even if they are all after
> "Put in Standard Form" phase.
>
> cheers,
> -Paul
>
>
>
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET