Update Extended Service Questions

Issue raised by: Lesley Bezear 3 Jul 1996

• Why is it not possible to have different actions for records in the same task package?
• Is it possible to add elements or update repeating elements in a record being updated?
• Why isn't there a maximum package size?
• What was the thinking on these issues when the Update Extended Service was developed?

Why is it not possible to have different actions for records in the same task package?

For simplicity of the specification. An action applying to each record was seen by the Extended Services developers as un-necessary and overly complicated. If you have separate Actions, use separate task packages. Since there are only four actions, this would mean at most four task packages.

Is it possible to add elements or update repeating elements in a record being updated?

Only if the action is recordReplace (i.e. whole record supplied). For elementUpdate, the standard is quite clear about this:

for elementUpdate, ... for any element within a supplied record, if there is no corresponding element within the database record, if there is more than a single occurrence of the corresponding element, ... the update will not be performed for that record.

Again, this is for simplicity; it was felt that to allow these these types of actions would potentially cause serious complications.

Why isn't there a maximum package size?

"Message size" in Z39.50 applies only to records returned in a Search or Present response. There has been suggestions to add message size limitation negotiation for other services, for example Scan. But on the other hand, there have also been suggestions to eliminate (or greatly simplify) the message size parameters altogether, in a futute version. This needs further ZIG discussion.

What was the ZIG's thinking on these issues when the Update Extended Service was developed?

Here is a brief history of the Update ES development: for a number of years, dating back almost to the inception of Z39.50 (1984), database update as a Z39.50 service was debated, and was controversial. There was an Update service (actual Z39.50 service, not an ES) drafted around 1987, similar in functionality to the current Update ES. But not until there was a clear articulation of Extended Services did it become clear that that's what Update really was, not a mainline service, but an extended service, because the actual update action was to be performed in background, not in Z39.50-real-time. Note that extended services was not developed with Update in mind; Update was an afterthought. Among the interested parties who developed the Update ES there was agreement that Update should be kept as simple as possible, as long as it met the requirements posed. As such it is already quite complicated as extended service go, and the emphasis was to keep it from becoming more so.