Document Replacement in a Provide and Register

This page shows how to construct a Document Replace request for submission by a Document Source. The approach is the same for other types of relationship type associations. Note that the inner details of each object is left out so that the structure of the submission is clear. Other examples show these details. Also note that some id attributes are show with symbolic values and some with UUID values. The ids with UUID values must have UUID values because they are referencing objects already in the registry. Object coded with symbolic (non-UUID) id values could have been code with UUID values - implementer's choice.

First, since this is a submission it must have a SubmissionSet object:

<RegistryPackage id="SubmissionSet">
  <Classification classifiedObject="SubmissionSet01"
                classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" id="ID_446196_1"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"/>
</RegistryPackage>

The classification is shown since without it the RegistryPackage is not a SubmissionSet. Next to replace a document, you must submit a document and that means the metadata must include a DocumentEntry object:

<ExtrinsicObject id="Document" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"/>

The ExtrinsicObject is the 'extensible' object type in ebRIM and the objectType attribute makes the ExtrinsicObject a DocumentEntry. For this to be a valid Provide and Register transaction, a document must be attached that matches up with this ExtrinsicObject/DocumentEntry. That is where the MTOM coding comes in but that is discussed elsewhere.

Next, for the submission of this DocumentEntry to be legal, it must be attached to the SubmissionSet object via a HasMember association:

<Association
                associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember"
                sourceObject="SubmissionSet" targetObject="Document" id="ID_446196_2"
                objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association">
            <Slot name="SubmissionSetStatus">
                    <ValueList>
                        <Value>Original</Value>
                    </ValueList>
            </Slot>
</Association>

A point of frequent confusion is the ids assigned to the objects. I chose SubmissionSet and DocumentEntry in this example because they were descriptive and they help me read my own metadata later. I could have chosen i558 and j334 as the names instead, as long as I was consistent within the message. These are local references, nothing outside this message references these objects, yet, so they don't require UUID format ids. Since these are symbolic names instead of UUIDS, the Document Registry will assign UUIDs to them before storing them. If you want to know the permanent UUIDs assigned to your objects without using queries after the submission, then assign UUID style values in the submission.

So far we have a valid submission of a new document. Now to make it into a replacement of an existing document we have to add the following RPLC association:

<Association id="Assoc1" sourceObject="Document" targetObject="urn:uuid:ba489ac1-0acb-4c31-a630-b18a305ee3eb"
     associationType="urn:ihe:iti:2007:AssociationType:RPLC"/>

This association links the new DocumentEntry to the original DocumentEntry indicating the relationship is replacement. How did I get the value for the targetObject? Usually this is done via a query but I could have remembered it if I was the one who submitted it originally and I submitted it with an id value in UUID format. This second approach does have a potential problem. If someone else has already replaced this DocumentEntry then my replace will fail since the original DocumentEntry will have status of Deprecated instead of Approved.

Finally, when submitted, the Document Registry will validate that the original DocumentEntry exists and has status Approved.