Re: CaveXML work plan - final Task List?

New Message	Reply	About this list	Date view	Thread view	Subject view	Author view

From: Peter MATTHEWS (matthews_at_melbpc.org.au)
Date: Sun Apr 28 2002 - 09:53:12 CEST

Previous message: Alexander Nickolsky: "XML we use"

Content-Type: text/plain; charset="us-ascii"; format=flowed
Date: Sun, 28 Apr 2002 17:53:12 +1000
From: Peter MATTHEWS <matthews_at_melbpc.org.au>
In-Reply-To: <5.1.0.14.1.20020315112842.01d4d210_at_popa.melbpc.org.au>
Message-Id: <5.1.0.14.1.20020417201506.01d82bf0@popa.melbpc.org.au>
Subject: Re: CaveXML work plan - final Task List?
To: cavexml_at_cartography.ch
Sender: owner-cavexml_at_karmail.ethz.ch
Precedence: bulk
Reply-To: cavexml_at_cartography.ch

Dear All,

Taking into account Alexander's and Martin's comments as below, and also
checking against our "Approach", here is the new proposed Task List - quite
a few mods. If there are no further comments in the next couple of days I
will load it on the web site and we can start work on the tasks. Of course
we should not hesitate to adjust this list as we go along. Thanks to
everyone who commented.

Regards,

Peter
=====================================================================

Tasks
=====
These are the individual high-level tasks to achieve our Objectives,
together with qualifying comments. Each task may involve several sub-tasks,
which can be worked out as we go. Some tasks can be worked on concurrently,
but in the background until their time comes, so that discussion will
remain better focussed on a single foreground task. However a list of who
is working on what will be included on this website. [Some temporary
comments appear below in square brackets. These will not appear on the
Tasks web page.]

1. Draw up the Scope, Objectives, and Task List for the project. [Done,
hopefully ;-)]
         Subject to review as required. Anyone is welcome to post suggested
changes
         to any of these at any time, which if generally accepted, will be
         incorporated.

2. Establish the official WG delegate for each interested country. [Not
started]
         This is purely for voting purposes as UIS voting is by country.
For the
         discussion and development work itself, everyone interested is
encouraged
         to participate.

3. Catch up with the work already done in this area. [Summary paragraphs
still needed]
         Each existing worker is invited to post a summary paragraph of
what they
         have done. If they also have a web page, this should be linked to
from
         their summary.

4. Establish a website and mailinglist for discussion and display of progress.
[Done, but the website will need further development to keep pace with and
encourage the technical discussion]

5. Publicise the project widely to encourage participation from the speleo
community.
         It is important for a successful standard that it be suitable for
the wide
         range of situations and practices used in various countries. It
should be
         noted that XML inherently uses Unicode, so all languages can be
handled.

6. Decide on the range of fields needed in a survey or mapping data transfer:

   6.1 Draw up survey and mapping data model(s).
       [I have prepared an initial draft diagram and entity definitions for
discussion.]
             These need to cover the range from raw survey data to final
             co-ordinates to map graphics.

   6.2 Define the various survey types to be covered initially.
            These could range from the simplest compass and tape survey through
            miner's dial and stadia, underwater techniques, theodolite and
chain
            or laser, triangulation, etc, both underground and on the
surface, and
            with the full range of units. Allowance is also needed for
techniques
            used in historic surveys so that these surveys can also be
handled. The
            purpose of this Task is to assess the range of fields and
approaches
            which we need to allow for. However for the pilot run right
through to
            a final standard we plan to choose a single, simple, commonly used
            survey type in order to get some early useable results (See
Approach).

   6.3 List and define the fields needed in each entity in the model(s).
       [Many fields already discussed]
            Include passing these fields on to the UISIC Field Definitions
WG for
            adding to the Field Definitions website.

7. Decide how CaveXML would fit into the overall scheme of survey and
mapping procedures.
    [Not really discussed yet but affects the overall scope of what we need
to do.]
         For example, what problems would it solve? What functions could it
perform?
         What auxiliary programs or files would be needed to let it perform
these
         functions? Include some block diagrams showing where CaveXML would
fit.

8. Decide on the technique(s) we will use to handle the transfer of map
graphics.
Just the technique(s) at this stage, not all the details.

9. Decide how many separate transfer formats will be needed.
For example, survey data, co-ordinates, and map graphics. Should
any or
all of these be combined?

10. Decide on the format to be followed by the written standard.
Suggestions have been that used by W3C, or by other groups producing
industry-specific XML markup languages.

11. For the chosen pilot survey type, design all the XML components required.
    [The guts of it at last... :-) Much discussion has already taken
place and
    various people have produced possible examples]
          Define the structure of each XML file required, including elements,
          atttributes, enumerated content options, data formats, and so on.
          Include DTD and Schema. On the website include regular working
drafts
          and concurrent documentation until the WG is satisfied with the set.

12. Publicise the draft of CaveXML as a "Request for Comment" (RFC).

13. Make any revisions after public comment.

14. Vote by our CDX Format Working Group delegates.

15. Ratification by the WG's parent, the UIS Informatics Commission (UISIC).

16. Produce training material.

17. List the software needed and organise it to get produced.

18. Publicise the CaveXML format after acceptance.
          This should await the training material and at least some
software so that
          CaveXML hits the road running. The publicity could include
endorsement at a
          UIS General Assembly, articles in caver, researcher, and cave
management
          journals in a range of countries and languages, Cavers Digest,
caving
          newsgroups, country-specific emailing lists, links on websites,
and so on.

19. Repeat Tasks 11-18 for the remaining initial survey types.

20. Further refinement and expansion as required.

=================== previous comment is below ===============================

At 01:57 22-04-02 +0100, martinl_at_talk21.com wrote:
>Could I suggest that the task list suggested by Peter be adjusted as follows?
>
>Basically, I think that the definition of formats (part of Pete's Task 5)
>is a task and then, for each format identified there, the task is to
>produce a specification document encompassing the rest of his task 5 and
>tasks 6-11. Concurrently, sample implementations and explanatory
>documentation would be produced. I would suggest that the document be
>along the lines of the W3C specifications.
>
>In addition, every attempt should be made to widen participation beyond
>the currently active Americans, British, and Australians with occasional
>Dutch, Czech and Russian contributions. Where are the French, Spanish, and
>Italians who survey their abundance of long and deep caves, assorted East
>European slavs and magyars with their long heritage of surveying caves,
>the Asiatics who have some of the largest caves in their countries, albeit
>often surveyed up to now by foreign expeditions?
>
>
>
>Tasks (Individual high-level tasks we need to do to achieve our
>Objectives.)
>===== [My comments shown in square brackets]
>
>o Draw up the Scope and Objectives for the group. [Done, but should remain
>open to review and revision]
>
>o Establish the official WG delegate for each interested country (UIS
>voting is by country). [Not started, and not probably terribly important
>to most participants. It is much better to have more enthusiastic and
>adept people involved directly than to burden a few worthy mouthpieces.]
>
>o Catch up with the good work which has already been done in this area:
>Each existing worker to post a "summary" of what they have done, as well
>as point us to their detail, e.g. via their web page. [Done, but should
>be summarised on the WG website]
>
>o Establish a website and mailinglist as a platform for discussion and
>publishing roadmaps, working drafts and results. [Done, but should be an
>ongoing task, encouraging feedback and improvement.]
>
>o Publicise the project as widely as possible through the international
>caving (and wider underground interest) communities to encourage
>participation and takeup irrespective of language. [This should be a
>priority from the start, not after standards have been formulated. XML is
>inherently internationalisable through its use of Unicode; XSLT can also
>assist in translating. This could also assist in revitalsing the UIS'
>dictionary project]
>
>o Decide on standalone transfer formats that will be needed (without
>restricting the possibility of combining them)
>e.g. survey data (raw and adjusted for corrections; simple to refined
>techniques (eg don't need to consider repeated readings, forward and back
>sights, etc for a simple line survey as used in , I suspect, the majority
>of surveys to date))
> survey co-ordinates (calculated or captured)
> graphics (2D and 3D).
>
> For each format:
> o produce a specification of an XML structured hierarchy of elements,
> and define their content in terms of attributes and/or text; enumerated
> content options, data formats. XML Schema, Schematron and possibly other
> means should be used to give precision to the definitions and assist in
> their implementation.
>
> [Peter Matthews has prepared an initial draft diagram and entity
> definitions for discussion, but not yet published (Didn't that French
> chap Fermat say something like that once?). Entities and fields are
> likely to be quite close to XML elements and attributes]
>
> o Produce regular working drafts for the proposed standards. [published
> on the website for discussion and revised in the light of comments
> submitted to a form on the website or via the email list, both archived]
>
> o. Provide documented software demonstrating a sample implementation of
> the standard. [this need not be done in parallel with the development of
> the standard, but I would expect parallel development to enhance the
> usefulness and practicality of both. I have a Java program which accepts
> from/to/distance/bearing/inclination of a format defined in an XML
> Schema, parses and validates it, calculates coordinates and draws a line
> survey using an SVG file and viewer]
>
>
>o Vote by WG delegates.
>
>o Ratification by UISIC.
>
>Regards,
>and lets get on with it!
>
>Martin Laverty

=========================================================================

At 16:23 08-04-02 +0400, Alexander Nickolsky wrote:
> > 5. Decide on the range of fields which we need to consider in a survey data
> > transfer:
> >
> > 5.1 Draw up a survey and mapping ERD (Entity Relationship Diagram)
> > recognizing the
> > difference between surveying and mapping data. [I have prepared an
> > initial draft
> > diagram and entity definitions for posting when we come to discuss it.]
> >
> > 5.2 Fill out the fields needed in each entity of the ERD. [Many already
> > discussed]
> >
> > 5.3 Define each of these fields.
>
>What could be added to p.5 is :
>
>-define subject areas - horizontal caves, all caves, land survey, GPS data,
>what else ? (Horizontal caves have some data and processing difference.)
>
>- define different surveying methods that should be supported by the format.
>Here I mean different technical things, i.e. different compass scales,
>measurement units, forward/backward shots, angular and absolute vertical
>measurements.

==================================================================================

At 10:07 24-03-02 +1100, Peter MATTHEWS wrote:
>Dear All,
>
>Sorry this email has been delayed in getting out - some things came up
>which I had to attend to.
>
>No further comments were received about the draft Task List, however I
>missed an earlier comment of Alexander's which is relevant:
>
>At 13:04 21-01-02 +0300, Alexander Nickolsky wrote:
>[snip]
>>Before being able to successfully design a standard format it seems
>>necessary to reach concensus on a common data model
>[snip]
>>The process of cave surveying has at least three stages, each of them
>>having its own data model.
>[snip]
>
>And these issues were also flagged up in the piece by Martin Heller and
>Andreas Neumann on our "Topics" web page under "Data model, Concepts" at:
>http://www.karto.ethz.ch/neumann/caving/cavexml/issues.html
>
>So we will need to allow for at least these three stages of data which are
>involved when we produce a cave map, namely, (1) the survey raw data, (2)
>the finally accepted co-ordinates of the calculated stations, sometimes
>with the walls/floor/ceiling, and (3) a digital form of the final drawn
>map. Sometimes Stage 3 will not exist of course, i.e. when the map is only
>on paper (as I understand it, the jury is still out on whether manual or
>computer aided map-drafting is easiest!). And there is also the other
>question which has been raised, namely the various sketches, including
>cross-sections, made in the cave and which form part of the raw survey
>data. Each of these stages contains a different type of data and *may*
>therefore need its own separate exchange/archiving format.
>
>Martin and Andreas' piece divides things up slightly differently to the
>above by citing stages of Survey, Model, and Views, but I am not sure at
>this stage that I totally understand what is in each (M+A can you
>elaborate a bit more than your following explanation?): "Survey includes
>the raw survey data, observations, and attributes; the Model defines
>morphological units, describes how to build their geometrical description
>and links them with attributes. Finally, the views define visual
>representations, such as perspective views, and the detailed maps and
>extended profiles as typically drawn in a CAD or illustration-package."
>
>So for your consideration here is my first simplistic attempt at revamping
>our original tasklist to take these factors into account:
>
>Tasks (Individual high-level tasks we need to do to achieve our
>Objectives.)
>===== [My comments shown in square brackets]
>
>1. Draw up the Scope and Objectives for the group. [Done]
>
>2. Establish the official WG delegate for each interested country (UIS
>voting is by
> country). [Not started]
>
>3. Catch up with the good work which has already been done in this area:
>Each existing
> worker to post a "summary" of what they have done, as well as point us
> to their
> detail, e.g. via their web page. [Done]
>
>4. Establish a website and mailinglist as a platform for discussion and
>publishing
> roadmaps, working drafts and results. [Done]
>
>5. Decide on the range of fields which we need to consider in a
>survey/mapping data transfer:
>
> 5.1 Draw up survey and mapping data model(s).
> [I have prepared an initial draft diagram and entity definitions for
> discussion.]
>
> 5.2 Fill out the fields needed in each entity of the model. [Many
> already discussed]
>
> 5.3 Define each of these fields.
>
>*. Decide how many separate transfer formats will be needed, e.g. survey
>data, co-ordinates,
> map graphics. Can/should some of these be combined into one format?
>
>*. Decide how we will handle the map graphics.
>
>6. Define the structure of each XML file required: root-element, nesting,
>elements
> and attributes, etc. [much discussion has already taken place; various
> people
> have produced possible examples]
>
>7. Produce regular working drafts for the proposed standards.
>
>8. Provide DTD and Schema of each XML file.
>
>9. Provide Documentation of the field definitions and data structure.
>
>10. Publish the Working Drafts for discussion and comments.
>
>11. Make Revisions after public comment.
>
>12. Vote by WG delegates.
>
>13. Ratification by UISIC.
>
>14. Publicise the format after acceptance.
>
>15. Produce explanatory and training material.
>
>16. List the software needed and organise it to get produced.
>
> *************************
>
>Your comments please...
>
>Regards,
>
>Peter

Previous message: Alexander Nickolsky: "XML we use"

New Message	Reply	About this list	Date view	Thread view	Subject view	Author view

This archive was generated by hypermail 2b30 : Tue Apr 30 2002 - 23:00:00 CEST