• documents
• plan
• regrep4
• createUpdateSemantics

This page has been superceded by the content of the latest RegRep 4 specifications.

This page defines the proposed semantics of update vs. create in RepRep 4.

Issues in RegRep 3

• There were two protocols Submit, Update which were very similar but different. This made implementation difficult due to duplicated and sometimes different behavior. Most people used the more flexible Submit (which allowed create and update).
• The semantics of the two protocols were overlapping and sometimes unclear. Submit allowed create + update while update allowed only update. Many detailed corner cases were not specified clearly. In particular behavior was not always clear regarding semantics of id and lid on Submit and Update.

Proposal for RegRep 4

In RegRep 4 the proposed changes in this area are:

• There is a single Submit protocol (no Update protoco).
• The Submit protocol has a attribute mode with choices:
  • create-only - Allows only creation of new objects
  • update-only - Allows only update of existing objects
  • create-and-update - Allows any mix of create and update (default)

Create-Only Mode Rules:

• lid MUST be specified by submitter
• lid MUST not exist
• id MAY be specified by submitter
  • If id is specified it must not exist
  • If id is unspecified it is generated by registry as a UUID based URN

  • If id is unspecified then it cannot be referenced by other objects in same [../../../regrep/SubmitObjectsRequest SubmitObjectsRequest]

Update-Only Mode Rules:

• Require id to be specified and exist
• If lid is specified it must match existing lid for that id
  • FN: Above adds extra performance overhead and complexity for a convenience of dubious value to client. Suggest we require both id and lid on update. This will allow lid to be required in all 3 cases simplifying processing.

Create-and-Update Mode Rules:

• Both id and lid MUST be specified

The table below articulates behavior for all identified cases for each mode of the Submit protocol