Task List

DRAFT 2005-05-02

This Edition: After a major rearrangement to suit the new work plan, this draft revision is for comment before finalisation. Previous versions.

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.

[ Top ]

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
Top | Contacts
Previous versions: 2004-09-26 | 2002-05-09 | 2001-01-12