Version 1.0, ...

Authentication

Although authentication and authorisation are an important aspect of practically every update system, the messages themselves do not carry any such information in the base profile. This is for two reasons:

1. The protocol cannot predict all of the business logic requirements that an authentication system might require
2. There are already mechanisms available for authenticating to a SOAP service, such as basic authentication in the HTTP layer

It is recommended that SRW's authenticationToken system be used if there are no other requirements. This system uses a token to identify the user, but does not specify how that token is initially obtained.

Records

Although Update does not specify a required record schema, nor does it assume that the records are maintained in any particular schema, records must be sent somehow. The schemas which the system will accept are recorded in the service description record, which is sent in the ExplainResponse message. The server will be prepared to accept any record which will validate against the schemas listed. If there is a preferred schema, it will be noted as the default schema in the configInfo section.

If a server accepts more than one record schema, the server will either transform the record into a native schema or save it as sent. Schemas other than those listed in the service description may be stored as sent or rejected.

Concurrent Editing

The protocol does not make any attempt to dictate how multiple people editing the same record is to be handled by the server, as different usage scenarios will require different solutions.

Recommended solutions include:

• Include a 'locked' status in the record's metadata and have users then set this flag while they are editing the record, and unlock it after they submit their changes.
• Use the recordVersions parameter to ensure that the change is against the most recent version of the record. Accept it if it is, otherwise it will be rejected as someone else has edited the record in the mean time.
• Use a system which tracks changes and accept the change if it does not conflict with other changes to the record.

Background Processing

While it is generally expected that the UpdateResponse message will be sent after all processing has been completed, this may not be feasable for large databases. Either the change to the record or any subsequent processing may be delayed such that the response cannot say whether the operation was a success or a failure, as it hasn't yet been completed.

In this case, the server should return an operationStatus of 'delayed'. The protocol does not specify a mechanism to identify the operation in a future request to discover if it has been completed or not, but solutions might include:

• Include a field in extraResponseData or a diagnostic which gives the operation an identifier to be used in a future request. Such a request is out of scope.
• Simply query the database to see if the change has taken effect.