The ISAF XRR message service allows instant integration of results management systems with the ISAF results database.  Use of the service allows for rapid publication of race and event standings so that regatta management teams can automate some of their office procedures.

Overall, the ISAF XRR service allows for these actions:

In order to make use of the ISAF XRR data service you will require regatta management software that is XRR enabled, to see a list of the available packages please follow the link to "Software Packages" above.

Alternatively, the following section covers the technical detail of integrating 3^rd party software with the ISAF XRR data service.

All XRR communications with ISAF are conducted through the URL:

http://datafeed.sailing.org

A connection is made by the client software using a standard HTTP connection - specific to the framework libraries that support your chosen programming language.

All communication objects should be set up to use UTF-8 encoding and the document content passed to our data-feed URL using the HTTP POST mechanism.  The following files contain examples of this implemented in a number of languages:

In the instance that the uploaded document content is malformed or has internal referential problems the HTTP status code of the response will be 404 and the content of the response will list each of the problems on a line by line basis (separated by new-lines), if the upload is valid the response code will be 200.

The import process works on a 3 stage basis: schema validation, internal reference validation, persistence.

Schema validation: The initial stage ensures that the document content meets the structural constraints of the chosen version of the XRR schema, this is done by using the standard XML DOM validation library facilities available in most programming languages.

Internal reference validation: This stage ensures that all of the unique keys necessary to link the various individual elements are in place. It also ensures that they haven't been used in multiplicity and that all IDs required for referencing the external (ISAF) unique references are in place and valid.

Persistence: This stage takes on three forms, depending on agreement between ISAF and the document source. An Event element may or may not have the attribute IFUploadCode populated, this attribute is described in technical specification v1.3.1. Assuming the document content passes the previous integrity checks the valid combinations are as follows: