Orienteering Interface Standards Project - Problem Investigation

This is a summary of the problems that have been discussed in the IOF standard interface project since meeting in Oslo October 1998. It is not easy to do a summary from all messages that we have received from both participants in project and other. In some cases we only give our conclusions just for trigging a new discussion.

Read this as the conclusion from the project management team!

Attributes

There is a proposal for attributes published 1999-01-15.

Conclusion

Some comments have arrived after latest version and a new version is needed.

After decision of syntax, a lot of work has to be done. If there will be a XML solution, someone has to write Document Type Definitions otherwise there is need for message definitions.

Maybe it is possible to test the attributes within use cases for common used tasks, e g entry, result report. We suggest that one case, result reporting, is pilot for test and discussion. Then it is possible to make several proposals for solve the same problem with different behaviour and from different approach.

Syntax

The method for transferring information to and from an orienteering administration application must be reliable, extendable and easy to use both for programmers and users with primitive equipment.

Alt I - Pure XML

XML is, like HTML, a standard based on SGML but it has more abilities to be extended than HTML. Pure XML standard means that IOF interface standards will use XML as it is. Our application only adds Document Type Definitions (DTD).

Example
<Event Name="National Event 1">
<Venue>Wherever</Venue>
<Date>03/01/1999</Date>
<Class Comp="M18A">
<Results> <Competitor StartNumber="24"> <Person Class="M18" ID="222673" ClubName="Manchester and District Orienteering Club" ClubID="MDOC" sex="M" Nationality="GBR"> <Name><family>Watson</family><given>Kevin</given><given>David</given></Name> <BirthDate Year="1981" Month="01" Day="24"/> <Address>52 Leegate Road,Heaton Moor,Stockport,SK4 4AX,UK</Address> </Person> <CCardData Type="Emit" Num="46"> <Splits>1:46 2:56 4:03</Splits> </CCardData> <Times Start="10:32:00" Fin="11:51:12" Result="1:19:12"/> </Competitor ></Results> </Event>

 

Alt II - Pure XML with comma separated data in lower level data structure

Example
<Event Name="National Event 1">
<Venue>Wherever</Venue>
<Date>03/01/1999</Date>
<Class Comp="W10A">
<I>1,"Elizabeth","Fowler","BADO",00:38:50,C,GBR,GBR389354,,,11:01:00</I>
<I>2,"Alice","Graham","SOC",00:40:40,C,GBR,,,,12:29:00</I>
<I>3,"Jennifer","Truby","SN",00:49:00,C,GBR,GBR345873,,,12:25:00</I>
<I>4,"Rachel","Cooper","SOC",00:55:06,C,GBR,,,,10:45:00</I>
</Class>
</Event>

 

Alt III - Simplified XML

Same as pure XML but with some restrictions and simplifications.

Example
<Event Name="National Event 1">
<Venue>Wherever</Venue>
<Date>03/01/1999</Date>
<Class Comp="
M50L">
<Results> "1" <Competitor "DNS"> <Person "222671" "Manchester and District Orienteering Club" "MDOC" Nationality="GBR"> <Name "Watson" "Ian"> </Person> <Times Result time="1:13:17"> </Times> </Competitor> </Results> </Class> </Event>

 

Alt IV - Fixed format

A message with fixed format and delimited with a special character, e g a comma.

Example
"D10A",1,"Elizabeth","Fowler","BADO",00:38:50,C,GBR,GBR389354,,,11:01:00
"D10A",2,"Alice","Graham","SOC",00:40:40,C,GBR,,,,12:29:00

 

Conclusion

There is no clear way but we see that XML is very powerful and most of the participants in this project promote for a XML based solution. We suggest that pure XML will be the primary syntax for information interchange. If there is a need for a simple fixed file format in future, we have to add that in next revision but it must be rudimentary.

A tool is needed for data conversion and syntax checking to success in promotion of XML. We presume that someone will offer IOF a low cost tool or library to simplify use of the new standard.

Character set

Latin-1 (ISO 8859-1)

 

Unicode

 

Free – declared by an attribute

An attribute in message declares what codeset that are used.

 

Multiple attributes

Use of multiple attributes representing same value in different codesets. E g name in a standard codeset and local name in local codeset declared by a codeset attribute.

 

Conclusion

Almost all is suggesting all major text fields in Latin-1 codeset with possibility to add one or several copies coded in alternated codeset. An attribute in message declares used codeset for local texts.

Position

For position of control we need a position format that are understandable for all.

WGS-84

 

Free – declared by an attribute

An attribute in message declares what position format that is used.

 

Conclusion

We are not able to do any suggestion from the two messages that have arrived in this subject. More discussion is needed.

External equipment

Maybe we need a different way to communicate with external electronic equipment e g electronic punching systems and finish line clock.

API with device driver

An Application Program Interface with common functions and data structures.

 

Common message

A common data structure.

 

Conclusion

There has not been any discussion after meeting in Oslo in October but almost all was agree that an API is preferable.

Someone have to identify the functions and declare the data structures for communication with the device driver.

Interface Standards Main

IOF Technology Development Committee
Orienteering Interface Standards Project
Stefan Nordmark
stefan.nordmark@tonshammar.se


Copyright 1999 [International Orienteering Federation]
Revised: 26th September 1999