odds_bundles

Extending content bundles to support On-Demand Document Source

Use cases

We need to create and store content to be sent by an On-Demand Document Source. The first submission is a OD Register transaction which sends the OD DocumentEntry to a Document Registry. The rest of the submissions are versions of the On Demand content which includes both document content and the SubmissionSet/DocumentEntry submission of the metadata.

OD submissions are a dynamic process. At the outset is the submission, directly to a Document Registry, of the On Demand Document Entry and its associated SubmissionSet. Later, triggered by Retrieve requests to the On Demand Document Source (which is as much a Repository as it is a Source), new versions of the document are installed possibly followed by a Provide and Register transaction to a Repository/Registry pair.

Each retrieve request to the OD Document Source can generate new content, a new version of the document. It can also return the previous version. This choice must be modeled using a content bundle.

Here we define how content bundles will be used to model on demand content. In a separate document we will document the processing done by the OD Document Source to use this content.

Summary of the extensions

To summarize the requirements, the content bundle must supply:

• On Demand document registration material
• Sequence of stable document submissions
• A skip which is defined as a retrieve request to the OD Document Source that returns the previous version of the document, no update is supplied. Thus the update part is skipped.

On Demand bundle labeling

A bundle intended for use with the On Demand Document Source has in its bundle.properties the property type with value on-demand.

On Demand Document registration

This is the first section according to index.idx. In section.properties is the property type with value on-demand and the property named transaction with value OnDemandRegister.

The section contains the files section.properties and metadata.xml.

Metadata.xml contains the metadata to be submitted as part of the registration of the On Demand DocumentEntry. This normally includes a SubmissionSet, a DocumentEntry, and a HasMember Association linking them. In metadata, the template variable $patient_id$ is used to indicate where to insert the Patient ID. The outer-most XML element of the metadata is SubmitObjectsRequest. The SOAP and other wrappers are supplied by the test client in toolkit.

Stable Document Submission

All other sections in an On Demand bundle are stable document submissions. In section.properties is the property type with value stable and the property transaction with value ProvideAndRegister

The section contains the file metadata.xml and one or more document files.

Metadata.xml contains the metadata to be submitted as part of the Provide and Register of the stable document.

Each document file contains the content of a single document.

Document files are linked to DocumentEntry (ExtrinsicObject) objects in metadata.xml through section.properties. There must be a linkage between the value of ExtrinsicObject.id and the document file name. Each value of ExtrinsicObject.id is a property name. The property value is the file name of the document file. This is the local file name without path prefix. The names type and transaction may not be used as ExtrinsicObject.id values since there usage in section.properties has other meaning.

Specifying submission skips

Each retrieve request to the On Demand Document Source triggers the use of a single section in the bundle. To enable skips we allow index.idx to contain a special term that does not reference a directory in the bundle. This special term is the keyword skip. This means that when looking to index.idx to see what is the next submission to generate, if the next index.idx term found is skip then no new content is registered - the existing content is returned. This implies that there can never be a real section named skip.