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. A list of who is known to be working on background or ongoing tasks is included below. Most tasks will have a separate page to show their detailed progress. We are covering a solution first for a simple survey type, then for the more complex survey types, and then for mapping. We will work on multiple tasks simultaneously where they are relatively independent of each other and it seems expeditious to do so.
[ Current tasks ]

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 later voting purposes as UIS voting is by one vote per country participating in the Working Group. For the discussion and development work itself, everyone interested is encouraged to participate.

3. Catch up with the work already done in this area

Everyone who has already done work in this area 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 mailinglist and website 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 initial simple survey type

Choosing a simple type initially is to enable a pilot standard to be produced more quickly as per Approach Item 5, but the detail to be included in the type chosen should be comprehensive enough to make this pilot standard actually useful. [ Progress ]

7. Decide how many transfer formats will be needed

Will we need separate transfer formats for survey data and for co-ordinates?

8. Design the basic CaveXML file structure and approach

This would address for example DTD & schema, file preambles, approach to element definitions, etc etc, but no actual element definitions yet, only examples. We should end up with template XML file(s) and a set of rules on how to specify elements and how to populate the files with data. These files and rules would suit any kind of cave/karst data as well as survey data. We would consider using someone's existing XML work as a starting point, and should review the work done by other groups who have produced industry-specific XML markup languages, e.g. LandXML and Geography Markup Language (GML). The final part of this task would be incorporating the results of the Sequencing/Grouping task below.

8.1 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 we are satisfied with the set [ Progress ].

8.2 Incorporate the results of the Sequencing/Grouping task

9. Decide how to handle survey data sequencing/grouping

There is a need to have survey data sequenced and grouped in various ways for various purposes. This task would examine how this need could be achieved and how CaveXML would handle it. Once the basic issues and methods were resolved, the results would be incorporated in the file structures established in the design task above.

10. Define the fields needed in the pilot survey data transfer:

First establish a cave survey data model then use this to help ensure that we have identified all the fields which will need to be covered, but only in the chosen simple survey type at this stage. The remaining fields for the more complex survey types will be identified in a later task.

10.1 Draw up the survey data model

This will cover all data entities needed in the range from raw survey data to final co-ordinates, and the relationships between them. [ Progress ]

10.2 List and define the fields needed for the pilot in each entity in the model

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

11. Put the draft CaveXML standard together

We now pull together all the elements established above into a complete document ready for public comment.

11.1 Decide on the format to be followed by the written standard

Suggestions have been that used by W3C, or by other groups who have produced industry-specific XML markup languages, e.g. LandXML and Geography Markup Language (GML). Should the document original be in HTML for maximum compatibility while being worked on, and published versions be in PDF?

11.2 Summarise how CaveXML relates to cave survey and mapping procedures

For example, what problems does it solve? What functions does it perform? What auxiliary programs or files are needed to let it perform these functions? Include some block diagrams showing where CaveXML fits. This would form part of the Introduction in the standard.

11.3 Prepare the complete draft standard

Having decided the format (html?), produce full drafts for discussion until we are satisfied it is ready for public comment.

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

13. Produce training material

Work on this could commence as soon as the final draft for the RFC is completed, or even before.

14. Make any revisions to the RFC after public comment

Discuss the revisions until we are happy with the RFC.

15. Vote by Working Group delegates

According to UIS rules this is one vote per country which is participating in the Working Group, and is cast by the country's delegate to the Working Group.

16. Ratification by the parent UIS Informatics Commission (UISIC)

The Working Group is part of the UIS Informatics Commission, and this is only a formality to assist official endorsement by UIS.

17. List the software needed and organise its production

We will need to produce specifications and call for volunteers.

18. Publicise the CaveXML format after acceptance

This should probably await the training material and at least some software so that CaveXML is actually ready to go. 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. Decide and prioritise the further survey types to be covered

Having produced a pilot standard using a simple survey type, we now need to expand it to cover the more complex survey types in priority order as per Approach Item 6. These could include miner's dial and stadia, underwater techniques, theodolite and chain or laser, levelling, triangulation, resection, laser sectioning, 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 they can be included.

20. Repeat Tasks 10-18 for the further survey types

This will include defining the extra fields needed.

21. Further refinement and expansion as required

As CaveXML comes into general usage, there will of course be a need to improve it in various ways.

22. Commence work on the transfer of cave map graphics

The approach to transferring cave map graphics is likely to be quite different to what we use for transferring survey and co-ordinate data.

Background Work

The following people are working on aspects of these pending and/or ongoing tasks. This work would not normally appear in ongoing mailing list discussion, so their names are listed here in case you need to contact them. Please advise the website manager if your name should appear here also.

4. Establish a mailinglist and website for discussion and display of progress

Martin Laverty (discussion summaries)

Steff Näff (discussion archiving)

Peter Matthews (website and mailing list manager)

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

Martin Laverty

8.1 Design all the XML components required for the chosen pilot survey type

(people who had already designed their own XML files for survey data)

Martin Heller

Richard Knapp

Devin Kouts

Mike Lake

Martin Laverty

Andreas Neumann

10.1 Draw up the survey data model

Peter Matthews