When a note pad connector calls the XCF Note Pad Services to replace, write, or delete an existing note, an instance number comparison can optionally be performed to ensure that the correct instance of the note is being manipulated. The creator of the note pad can specify the INSTCOMP keyword to indicate whether connections are required to perform instance number comparisons when updating and deleting notes. This protocol applies only to requests that replace, write, or delete a single note. When writing a note, the protocol applies only in cases where the note already exists (in which case the write request is processed as a replace request). Since multi-note requests do not support instance number comparisons, they are not subject to this protocol.

If INSTCOMP=DISCRETIONARY is specified by the creator of the note pad, instance number comparisons are optional. When a connection issues a request to replace, write, or delete a note, XCF will process the request regardless of whether an instance number comparison was specified. An instance number comparison will be performed if specified, otherwise not.

If INSTCOMP=REQUIRED is specified by the creator of the note pad, instance number comparisons are required. When a connection issues a request to replace, write, or delete a note, XCF rejects the request if the connector fails to provide a nonzero instance number for comparison. When replacing or deleting a note, the request is immediately rejected if an instance number of zero is specified. When writing a note, the request proceeds. If the note exists, the write is processed as a replace and the request is rejected if the instance number is zero.

Typically, the note pad creator might insist that instance number comparisons be performed as a safeguard to help ensure that the application implementation adheres to certain conventions. Requiring instance number comparisons might help ensure that the application always detects cases where the note was changed out in the note pad. Ostensibly the intent is to prevent the accidental loss of note data. However, simple detection of a stale copy of the note is not sufficient. The application will likely need to read the note and reapply the desired changes to the latest copy of the note before it reissues the rejected replace request.