From: dkouts (dkouts_at_cox.rr.com)
Date: Sun Jan 20 2002 - 07:37:50 CET
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 485199D72 for <cavexml-outgoing_at_ethz.ch>; Sun, 20 Jan 2002 04:43:23 +0100 (CET) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id 63AE39D5C; Sun, 20 Jan 2002 04:43:20 +0100 (CET) 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 7D1A29D72 for <cavexml_at_cartography.ch>; Sun, 20 Jan 2002 04:43:19 +0100 (CET) Received: from Mail6.mgfairfax.rr.com (fe6.southeast.rr.com [24.93.67.53]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 11B0F8A45 for <cavexml_at_cartography.ch>; Sun, 20 Jan 2002 04:43:16 +0100 (CET) Received: from cox.rr.com ([24.168.160.193]) by Mail6.mgfairfax.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Sat, 19 Jan 2002 22:39:08 -0500 Message-ID: <3C4A65BE.4020602@cox.rr.com> Date: Sat, 19 Jan 2002 22:37:50 -0800 From: dkouts <dkouts_at_cox.rr.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us To: cavexml_at_cartography.ch Subject: Re: CaveXML work plan References: <5.1.0.14.1.20020119112355.049866c0_at_popa.melbpc.org.au> <3C4A29D7.6DE146FF_at_speleonics.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
I support Mike's suggestion below...
"...The way we can avoid this is to make sure that members of this group who have
written cave surveying software packages get their data structures and their
capabilities into the documentation...."
But I suggest that we not constrain ourselves to "members of this group who have written cave surveying software". That would be a little self-serving. I know for a fact that the authors of many of the most popular cave survey software packages (Garry Petrie, Olly Betts, Larry Fish, Taco van Ieperen, David MacKenzie, etc.) are not active participants in this work group. Instead, they are largely observers, waiting to see if this body will produce something that meets their requirements.
In fact, I performed requirements development interviews with many of these leading developers of cave surveying software in 2000. I brought their inputs together in a matrix analysis that was designed to illuminate the cave survey data elements common to each author's schema, as well as point out those that were unique.
While it is perfectly acceptable to reinterview those developers, should anyone choose to do so, for the same information, it might not hurt the interviewer to first familiarize themself with the information already collected and presented on this subject at - http://www.psc-cavers.org/xml/Analysis.html
Devin
Michael Lake wrote:
>Peter MATTHEWS wrote:
>
>>haven't really established any conclusions yet. It is time we reviewed
>>where we are at, and where we go from here.
>>
>
>Yes.
>
>>Objectives (The broad targets we want to achieve)
>>=========
>>1. Produce a data format which is hardware and software independent for the
>>transfer and the archiving of speleological data, including data for cave
>>surveying and mapping, and utilising existing international transfer
>>standards such as XML and related standards if possible.
>>
>
>As XML is more than just a 'transfer' standard should we drop the word
>transfer in "existing international transfer standards"? It would then
>just read "utilising existing international standards".
>
>>Approach (The overall way in which we want to tackle the project)
>>========
>>1. Understand and document the data structure of a cave survey. Include in
>>the documentation as many variations of survey method as possible.
>>
>......
>
>>3. Prepare a pilot CaveXML draft standard to completion, one which is
>>limited to a commonly used simple form of cave survey.
>>
>
>I think this would help as I have been a bit overwhealmed by the complexity
>of what XML is required in order to handle all survey formats.
>The problem however is picking a simple format. Someones survey format will
>be developed by the group while others may see that their more complex,
>better, more advanced format, is ignored.
>
>The way we can avoid this is to make sure that members of this group who have
>written cave surveying software packages get their data structures and their
>capabilities into the documentation as in Part 1 of Approach above so that it's
>written into the road map that implementation of their requirements into the CaveXML format will not be forgotten.
>
>So yes I like the idea that we "documentation as many variations of survey method
>as possible", then pilot CaveXML draft standard to completion ... "limited to
>a commonly used simple form" and finally "expand .... to cover the more complex alternatives".
>
>>8. Provide DTD and Schema.
>>
>
>Have we decided to do both or just a Schema?
>
>Best wishes
>Mike
>
>PS. An "Alexander Nickolsky" has emailed saying that he has done some
>work on a Cave XML format like mine. I have sent him the info on our
>group (web page and mailing list) and hopefully he will join us.
>
This archive was generated by hypermail 2b30 : Thu Jan 31 2002 - 23:00:01 CET