XDS Notes from 2008 NA Connectathon

From IHEWiki

Jump to: navigation, search

The following notes document things learned at the NA Connectathon. Each of these notes will be submitted as Change Proposals to update the Technical Framework following the European Connectathon. We are publishing this to the European Connectathon attendees so they can take advantage of what was learned in Chicago in January.

  1. In metadata when an optional Slot is not used, it must not be present (Slot <Value/> element cannot be empty)
  2. In XDS.a it is very clear where SOAP with Attachments may/must be used. The same expectations must be established for MTOM/XOP (XOP is an upgrade to SwA). XOP is appropriate on Provide and Register.b Request and Retrieve Multiple Documents Response only. We need to evaluate currently available toolkits, MS, Axis2 etc., to see that this level of control is feasible. The standard gives us the flexible we need. Now that the NA Connectathon is over we will evaluate the XDS test kit and provide updates as appropriate.
  3. The metadata attribute XDSDocumentEntry.uniqueId has the format OID^EXT where the ^EXT is optional. This value is frequently used in generating the XDSDocumentEntry.URI attribute. The challenge is that XDSDocumentEntry.URI must be a valid URI and the ^ character is not allowed in a URI. This means that the value placed in XDSDocumentEntry.URI must be URI Encoded according to the rules of HTTP standard. (get quote and example).
  4. With the creation of XDS.b, Document Consumers need an easy way to determine which of the retrieve transactions, Retrieve Document and/or Retrieve Multiple Documents, can be used with a particular Document Repository. The following rule was developed at the NA Connectathon and enforced with the Repository vendors present. If the XDSDocumentEntry metadata contains the URI attribute then the Repository shall accept the XDS.a Retrieve Document transaction for that document. If the XDSDocumentEntry metadata contains the repositoryUniqueId then the Repository shall accept the XDS.b Retrieve Multiple Documents transaction for that document.
  5. Document Repositories need to be aware that XDSDocumentEntry objects received in a Provide and Register (.a or .b) may contain the following attributes: size, hash, URI, repositoryUniqueId. To understand the source of these attributes, remember that the metadata sent to the Repository by the Document Source could have been received by the Document Source via transaction from the XDR or XDM profiles. The Document Repository is responsible for removing or updating these attributes. This is particularly important relevant to the last note related to the URI and repositoryUniqueId attributes.
  6. Audit log testing was a disaster leading up to the NA Connectathon. First we found that updates are needed to the audit requirements for most of the XDS transactions. Second, many implementers struggled to interpret some parts of the specification. To try to make progress, we published a set of refinements/clarifications to the profile requirements. These were published in the IHE Wiki and announced on the Connectathon mailing list. These requirements will again be tested at the European Connectathon. The Wiki document can be found at http://ihewiki.wustl.edu/wiki/index.php/XDS_Syslog_testing_requirements.
  7. As we have done each year, we have again refined our approach to validating XDS tests. One change of interest to Document Source implementers will be enforced at the European Connectathon. In the past we have carefully evaluated the metadata stored in the Document Registries. In April, we will also carefully evaluate the content (document) submitted to see that it matches the coding in metadata. At Connectathon we will evaluate that the document submitted matches the mimeType attribute placed in the XDSDocumentEntry. XML documents must parse, PDF must validate against a PDF parser.
  8. As the testing of XDS actors has matured, we have found that we need to establish rules for the operation of Registries and Repositories at Connectathon to enable proper testing and proper support for the testing of Document Sources and Consumers. The following rules will be enforced at the European Connectathon. XDS Registry and Repository implementations shall:
    1. Be available on the local Ethernet from noon Monday to noon Friday during normal Connectathon hours. Please adjust these times to match the published times for the Connectathon.
    2. If you bring both a Registry and Repository, both must be available full time during the normal Connectathon hours.
    3. If you bring both an XDS.a version and an XDS.b version of a Registry or Repository, both must be available full time during normal Connectathon hours.
    4. No clearing of databases. Data submitted on Monday must be available for query/retrieve on Friday.
  9. Like we did at the North American Connectathon, testing of Life Cycle and Folders will be optional at Oxford. With XDS.b and ATNA audit log as new work to test, time is not available to do proper testing of these features as well.
  10. The European Connectathon will use a Certificate Authority to manage certificates for the TLS portion of ATNA. This is different from Chicago where we used self-signed certificates. Certificates will be available for testing before we travel to Oxford so that basic testing can be done at home. A certificate will be assigned for the Public Registry. The local copy of the Public Registry that is brought to Connectathon will have its own certificate.
  11. Document Sources must use the Connectathon Objects page in kudu to document details about the documents they submit to Repositories/Registries, so that other systems can find them. Likewise, Document Consumers should use this page to help you find documents you will retrieve.
Personal tools