Difference between revisions of "XDS Implementation Notes"
| Line 11: | Line 11: | ||
While new material is to be added to this page, there is older material available from the original [http://ihewiki.wustl.edu/wiki/index.php/XDS-FAQ XDS FAQ] | While new material is to be added to this page, there is older material available from the original [http://ihewiki.wustl.edu/wiki/index.php/XDS-FAQ XDS FAQ] | ||
| + | |||
| + | |||
| + | [[Category:Profile Implementations]] | ||
Revision as of 17:16, 21 May 2008
This page documents implementation notes for general XDS, the issues that are shared by many or all XD* profiles.
All Transactions
Duplicate Metadata
Document Source(s) can submit a document multiple times. This results in a XDSDocumentEntry.uniqueId being present on multiple XDSDocumentEntry objects in the Registry. As long as the size and hash attributes are the same, this is considered a normal condition that a Document Consumer must be prepared. This condition can occur for two other reasons. First a Provide and Register transaction can fail because the response message from the Repository back to the Document Source is not delivered. This can happen on a synchronous connection as well as with asynchronous web services as described in the new Async XDS Supplement. A natural response for the Document Source is to resubmit, again causing duplication.
A document replace (RPLC from LifeCycle Management option to XDS) has the known issue that a Document Source replacing a document is not required to find all copies of the document in the Registry. A replacement will be applied to only one copy of the document. Likewise the new topic of Metadata Versioning (currently a white paper) does not carry the requirement to find all copies of the document metadata.
Old XDS FAQ
While new material is to be added to this page, there is older material available from the original XDS FAQ