Task List

Below are the individual high-level tasks to achieve our Objectives. Each task may involve several sub-tasks which we can work out as we go. Some tasks can be worked on concurrently, but preferably in the background until their time comes, so that the discussion can remain better focussed on a single foreground task. A list of who is known to be working on background or in-progress tasks is included below. Each task will have a separate page to show detailed progress as we go along.

Task colour codes: Done | Current | Background | Future

1. Draw up the Scope, Objectives, and Task List for the project

These are subject to review as required. Anyone is welcome to post suggested changes to any of these at any time, and if generally accepted, they will be incorporated.

2. Establish the official WG delegate for each interested country

This is 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

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

5. Publicise the project to encourage participation from the speleo community

It is important for a successful standard that it be suitable for the wide range of speleo 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)

These need to cover the range from raw survey data to final co-ordinates to map graphics. [ Progress ]

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, levelling, 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, and 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)

Include passing these fields on to the UISIC Field Definitions WG for adding to the Field Definitions website.

7. Decide how CaveXML should fit overall in survey and mapping procedures

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) for handling 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. Design all the XML components required for the chosen pilot survey type

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 Working Group delegates

15. Ratification by the parent 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 probably 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

Background Work

The following people are known to be working on aspects of these pending tasks. Please advise the website manager if your name should appear here also.

11. Design all the XML components required for the chosen pilot survey type

Martin Heller

Richard Knapp

Devin Kouts

Mike Lake

Martin Laverty

Andreas Neumann