XDS Main Page
From IHEWiki
IHE XDS
The is the home page for XDS profile Testing. If you are new, I suggest examining the XDS Testing Introduction page and the IHE Links section below first. This page is intended to be a collection of reference material for testing and not tutorial in nature. XDS Testing Introduction is the best current introduction or tutorial on the subject.
IHE Links
IT Infrastructure Committee (home of XDS)
Download IT Infrastructure Profiles and Whitepapers
Implementation Notes
Official ITI Implementation Guide
XDS Notes from 2008 NA Connectathon
Updates for the 2008-2009 Testing Season
Nov 7, 2008
For vendors testing Document Repository or Document Registry actors, the key downloads are:
- xdstoolkit (formerly known as xdstest2, now includes xdstest) (must use xdstoolkit.2.00.zip or newer)
- testkit (test data to use with xdstest) (must use testkit.7.00.zip or newer)
- The test descriptions, as always, are available at http://ihewiki.wustl.edu/wiki/index.php/XDS_Test_Kit_Test_Descriptions
- The per-actor test requirements are posted at http://ihewiki.wustl.edu/wiki/index.php/XDS_Test_Kit_2009_Test_Requirements
- with more detailed instructions in the readme.txt file from the testkit
For vendors testing Document Source and Document Consumer actors, the key references are:
- http://ihewiki.wustl.edu/wiki/index.php/XDS_Test_Kit_Test_Descriptions
- http://ihewiki.wustl.edu/wiki/index.php/XDS_Test_Kit_2009_Test_Requirements
IMPORTANT: The Web Service Endpoints for this season have changed. The new endpoints are documented here
The listing of required tests for the various XDS actors are available here. Kudu is in the process of being updated to match this list.
As for status on a more detail level...
Done
- Updated Registry, Repository, and tests to reflect the last season's CPs.
- Ports and Endpoints for the Public Registry will be managed differently this year. The change will allow different certificate sets to be used for each major testing event without having to remove the certificates for the last event.
- New MTOM/XOP tests to reflect corrections to XDS.b/XCA profile
- Significant upgrade to the xdstest tool (yes, I renamed it back to xdstest, xdtest2 is just too hard to say in a sentence)
- No longer runs natively on Windows. Requires the use of a Un*x-like emulator such as Cygwin.
- New command line front end
- Manages patient ID allocation automatically
- Manages WS Endpoints from a common configuration table
- No longer any need to edit testplan.xml files
- log.xml files placed into separate directory tree
- Configuration controlled by a small collection of environment variables
- XDSTEST is no longer distributed as is. It is now part of a growing collection of tools. This collection has been named the xdstoolkit.
Plans (Yet to come)
- XCA tests
- Async Tests for both XDS and XCA - this will involve the use of a HTTP Proxy run on or near your development machine. It will accept async requests and forward them to the Public Registry server as sync requests. The response back to you will be async. This gets around corporate firewalls that will not allow incoming requests without a lot of begging and configuration.
- Tests and Public Registry upgrades to follow Metadata White Paper
- Make Repository implementation handle UTF-8 correctly and add tests for same
- Tests for PubSub White Paper (time permitting)
- Things I have forgotten to put on this list
Where to ask questions
We have a mailing list dedicated to XDS (and related profile) testing. It is ihe-xds-implementors@googlegroups.com. Discussion of ITI Profiles belongs on the ITI committee mailing list ititech@googlegroups.com. If you need to contact me directly, I have a new email address for IHE work bmajur AT gmail dot com.
Updates for the 2007-2008 Testing Season
- This wiki material has been moved to a new host. The new main support page for XDS Profile testing is http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page. If broken links are found please let me know. Also, if a wiki page that you depend on is not present, let me know. I have moved all of what I think folks are using but I might have missed a page. The old wiki on hcxw2k1.nist.gov is no longer being updated and will be turned off December 1.
- The Registry Adaptor, metadata validator, and the new test tool xdstest2 are new implementations based on the Apache Axis2 project.
- Error reporting software has been rewritten. This means no more cryptic JSP errors!
- Last year's implementation is still available for testing but is not being maintained.
- New server hardware is now installed. The old server is still running to support the RSNA demonstration at the end of November. Around December 1, it will be turned off. During this period of having two servers running, the old server will retain the hcxw2k1.nist.gov name and the new server will be addressed by its IP address 129.6.24.109. After the old server is turned off, the hcxw2k1 name (DNS) will be moved to the new server.
- The xdstest tool has been replaced by a new tool xdstest2. The old tool will not be used this season.
- XDS.a and XDS.b are both supported by this server. Documents and metadata submitted via one interface can be queried/retrieved via the other. There is one database behind the two interfaces.
- A syslog service will be available on the server. To support this service, a syslog browser will be available to inspect the syslog records you generate. There are new XDS tests that require you to submit syslog entries to this server.
- A new test log browser will be used this season. Unlike last season where the SOAP Header returned from a transaction included a link to a test log entry, this tool allows browsing of all test log entries submitted from your current IP adddress. See the tools section below for details.
- Test result reporting has changed. Tests run using the new test tool xdstest2 generate a log file named log.xml that is to be logged to Kudu. Tests run against the Public Registry now require logging in Kudu of the XDSSubmissionSet.uniqueId attribute. There is no longer any restrictions placed on the use of Patient IDs. For both style tests, old style of logging will not be accepted this season.
Testing
Rules for submitting results to Kudu
Do not submit zip files. Instead, submit multiple .txt or .xml files. If a test has two parts, submit and eval the submit to Kudu a submit.xml and eval.xml log files instead of a zip file containing both.
2009 Test Documentation
- a table of all the XDS tests indexed by the XDS transaction they support. Includes links to the documentation for each test
Test Descriptions/Instructions
- detailed description of all the tests with instructions for executing. At the top of the page is documented the rules of testing (what to submit as evidence, how to allocate Patient IDs etc). You can look directly here if you know a test number.
2007-2008 Test Documentation
- a table of all the XDS tests indexed by the XDS transaction they support. Includes links to the documentation for each test
Test Descriptions/Instructions
- detailed description of all the tests with instructions for executing. At the top of the page is documented the rules of testing (what to submit as evidence, how to allocate Patient IDs etc). You can look directly here if you know a test number.
2006-2007 Test Documentation
Testing XD* (2006-2007 season)
XD* Detailed test requirements (2006-2007 season)
General
Notes and test documentation for Async profile
- All the documenation on testing async web services can be found here.
- Notes on metadata and Soap with Attachments as used in the XDS.a profile.
- (Frequently Asked Questions regarding the XDS profile)
- table documenting all the UUIDs created by the XDS Profile.
Discussion of XDS Transactions
- this page offers discussion on selected topics on XDS Transactions.
- this page offers discussion on common metadata patterns
- All XML Schema files used to validate Registry/Repository related transactions.
Testing Tools
- Renamed to just xdstest, this is a command line tool that acts as Document Source, Document Consumer, and Initiating Gateway for testing partner actors. It is now packaged inside a larger collection of tools which are collectivly called xds toolkit. This toolkit can be downloaded from here. Xdstest is really just a script interpreter for a small XDS-oriented test language. The actual scripts which make up individual tests are packaged in the testkit (see below) for distribution. A FAQ is maintained here.
- a web page with a collection of tools. It includes the following tools:
- Patient ID allocator for the Public Registry
- A Web page for uploading your metadata for validation (a step that happens on every submission as well)
- Simple browser for querying the Registry and retrieving from the Repository
- Test Log browser - browse the content you submitted - useful for debugging and obtaining test results for Kudu upload
- Syslog browser - the Public Registry server has a Audit Log repository you can submit to. This browser lets you view your submissions.
Test Log Browser (documentation)
- a web based tool for browsing the test logs maintained on the Public Server. It detects the IP address from your browser connection and only shows log entries for transactions sent from that IP address.
- a web based tool for browsing audit log entries sent to the audit repository on the Public Server. It detects the IP address from your browser connection and only shows log entries for transactions sent from that IP address.
- This test kit contains scripts for testing server-based actors like Document Repository, Document Registry, and Receiving Gateway. It uses the xdstest tool to execute the scripts. The test kit is published here. Always download the most recent version. This testkit contains three main directories of test material: testdata containing scripts for initializing Registry and Repository actors for other tests; tests which are the tests; and examples which really are examples of things Document Source, Document Consumer, and Initiating Gateways have to do. Each test is contained in a directory with a number like 11745 which correspond to IHE tests documented in Kudu. Individual test documentation can be found on the wiki page here. A FAQ is maintained here.
- Facilities for testing asynchronous interactions with XDS.b and XCA. A FAQ is maintained here.
Public Registry
The Public Registry is a server maintained on the Internet which implements the following actors:
- Document Registry (XDS.a and XDS.b)
- Document Repository (XDS.a and XDS.b)
- Receiving Gateway (XCA)
- Audit Record Repository
The new Public Registry implementation resides at hcxw2k1.nist.gov (also known as ihexds.nist.gov and 129.6.24.109).
Configuration and Change Log
- that defines the Public Registry Affinity Domain configuration. This includes definitions of acceptable codes, mime types etc. The Metadata Validator function of the Public Registry validates all ProvideAndRegisterDocumentSet and RegisterDocumentSet transactions (XDS.a and XDS.b) against this configuration. Specifically, it passes the submitted metadata through Schema validation and then metadata validation. Metadata validation has two parts: validate that the metadata is structured according to the rules of XDS (which are more strict than ebXML Registry standard) and that the codes used in the metadata are consistent with the configuration of the Affinity Domain. Updates to this table are made on request to support community activities.
- Text file documenting changes and updates to the Public Registry server.
Test Event Configuration
Note: This table must be read carefully. Different events (North American Connectathon vs. European Connectathon) use different endpoints that are only different by a single field. This will allow event specific certificates to be available year-round.
Three variables are used in the main table below, YEAR, EVENT, and SEVENT. Use this section to determine the correct values for you.
Event Configurations
| Event Name | YEAR | EVENT (non-tls port) | SEVENT (tls port) |
| North American Connectathon in Chicago in Feburary 2009 | tf5 | 9080 | 9085 |
| European Connectathon in Chicago in April 2009 | tf5 | 9080 | 9001 |
Endpoints
| Transaction | non-TLS | TLS |
| XDS.a | ||
| Provide and Register | http://ihexds.nist.gov:EVENT/YEAR/services/xdsrepositorya | https://ihexds.nist.gov:SEVENT/YEAR/services/xdsrepositorya |
| Register | http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistrya | https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistrya |
| Stored Query | http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistrya | https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistrya |
| XDS.a and XDS.b Stored Query only differ by their SOAP requirements (See TF section 3.18.3) | ||
| SQL Query | http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistrya | https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistrya |
| Non-TLS SQL Query will return a non-TLS URI. TLS SQL Query will return a TLS URI. | ||
| XDS.b | ||
| Provide and Register - b | http://ihexds.nist.gov:EVENT/YEAR/services/xdsrepositoryb | https://ihexds.nist.gov:SEVENT/YEAR/services/xdsrepositoryb |
| Register - b | http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistryb | https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistryb |
| Retrieve Document Set | http://ihexds.nist.gov:EVENT/YEAR/services/xdsrepositoryb | https://ihexds.nist.gov:SEVENT/YEAR/services/xdsrepositoryb |
| Stored Query | http://ihexds.nist.gov:EVENT/YEAR/services/xdsregistryb | https://ihexds.nist.gov:SEVENT/YEAR/services/xdsregistryb |
| XDS.a and XDS.b Stored Query only differ by their SOAP requirements (See TF section 3.18.3) | ||
| Non-TLS Stored Query will return a non-TLS URI. TLS Stored Query will return a TLS URI. | ||
| XCA Receiving Gateway | ||
| Cross Gateway Query | http://ihexds.nist.gov:EVENT/YEAR/services/rg | https://ihexds.nist.gov:SEVENT/YEAR/services/rg |
| Cross Gateway Retrieve | http://ihexds.nist.gov:EVENT/YEAR/services/rg | https://ihexds.nist.gov:SEVENT/YEAR/services/rg |
| Initiating Gateway with Affinity Domain option | ||
| Stored Query | http://ihexds.nist.gov:EVENT/YEAR/services/xcaregistry | https://ihexds.nist.gov:SEVENT/YEAR/services/xcaregistry |
| Retrieve Document Set | http://ihexds.nist.gov:EVENT/YEAR/services/xcarepository | https://ihexds.nist.gov:SEVENT/YEAR/services/xcarepository |
| Asynchronous Web Services | ||
| Provide and Register - b | http://ihexds.nist.gov:EVENT/YEAR/services/repositorybas | https://ihexds.nist.gov:SEVENT/YEAR/services/repositorybas |
| Register - b | http://ihexds.nist.gov:EVENT/YEAR/services/registrybas | https://ihexds.nist.gov:SEVENT/YEAR/services/registrybas |
| Stored Query | http://ihexds.nist.gov:EVENT/YEAR/services/registrybas | https://ihexds.nist.gov:SEVENT/YEAR/services/registrybas |
| Retrieve Document Set | http://ihexds.nist.gov:EVENT/YEAR/services/repositorybas | https://ihexds.nist.gov:SEVENT/YEAR/services/repositorybas |
| Cross Gateway Query | http://ihexds.nist.gov:EVENT/YEAR/services/rgas | https://ihexds.nist.gov:SEVENT/YEAR/services/rgas |
| Cross Gateway Retrieve | http://ihexds.nist.gov:EVENT/YEAR/services/rgas | https://ihexds.nist.gov:SEVENT/YEAR/services/rgas |
Many tests use specialty URLs representing special testing services. These are documented in the individual tests.
This server is configured to accept/return the following configured values
repositoryUniqueId is 1.19.6.24.109.42.1.5
homeCommunityId is urn:oid:1.19.6.24.109.42.1.3
Important URLs / WS Endpoints
NOTE: With a new scheme for managing test events, the Endpoints below will continue to support version 4 of the Technical Framework (published in the fall of 2007). For endpoints that support more modern versions, see the previous section.
| Transaction | non-TLS | TLS |
| XDS.a | ||
| Provide and Register | http://129.6.24.109:9080/axis2/services/xdsrepositorya | https://129.6.24.109:9443/axis2/services/xdsrepositorya |
| Register | http://129.6.24.109:9080/axis2/services/xdsregistrya | https://129.6.24.109:9443/axis2/services/xdsregistrya |
| SQL Query | http://129.6.24.109:9080/axis2/services/xdsregistrya | https://129.6.24.109:9443/axis2/services/xdsregistrya |
| Non-TLS SQL Query will return a non-TLS URI. TLS SQL Query will return a TLS URI. | ||
| XDS.b | ||
| Provide and Register - b | http://129.6.24.109:9080/axis2/services/xdsrepositoryb | https://129.6.24.109:9443/axis2/services/xdsrepositoryb |
| Register - b | http://129.6.24.109:9080/axis2/services/xdsregistryb | https://129.6.24.109:9443/axis2/services/xdsregistryb |
| Retrieve Document Set (returns MTOM) | http://129.6.24.109:9080/axis2/services/xdsrepositoryb | https://129.6.24.109:9443/axis2/services/xdsrepositoryb |
| Retrieve Document Set (returns MTOM/XOP) | http://129.6.24.109:9080/axis2xop/services/xdsrepositoryb | https://129.6.24.109:9443/axis2xop/services/xdsrepositoryb |
| Both XDS.a and XDS.b | ||
| Stored Query | http://129.6.24.109:9080/axis2/services/xdsregistryb | https://129.6.24.109:9443/axis2/services/xdsregistryb |
| Non-TLS Stored Query will return a non-TLS URI. TLS Stored Query will return a TLS URI. | ||
| XCA Receiving Gateway | ||
| Cross Gateway Query | http://129.6.24.109:9080/axis2/services/rg | https://129.6.24.109:9443/axis2/services/rg |
| Cross Gateway Retrieve (return is MTOM/XOP coded) | http://129.6.24.109:9080/axis2xop/services/rg | https://129.6.24.109:9443/axis2xop/services/rg |
| Cross Gateway Retrieve (return is MTOM coded) | http://129.6.24.109:9080/axis2/services/rg | https://129.6.24.109:9443/axis2/services/rg |
Many tests use specialty URLs representing special testing services. These are documented in the individual tests.
repositoryUniqueId is 1.19.6.24.109.42.1
homeCommunityId is urn:oid:1.19.6.24.109.42.1.3
North American TLS
The configuration created to support the North American Connectathon January 2008 has been removed to allow for Europe 2008 testing. The two configurations are not compatible.
This season certificates are being handled differently, as an experiment. The certs that Steve has issued are valid for a full year and contain the hostname that you will be using at Connectathon. They are being used Pre-Connectathon and at the Connectathon. Hopefully this will avoid the last minute rush to install new certs. But, it is coming with some headaches. First, do not depend on the hostnames embedded in the certs for pre-Connectathon testing. Second, some folks have found it necessary to put the hostnames/IP addresses into their local host table for them to work. If you have other issues/solutions please let me know and I will post them here.
TLS (port 9443) accepts the following Cyphers:
- TLS_RSA_WITH_AES_128_CBC_SHA
- SSL_RSA_WITH_3DES_EDE_CBC_SHA
The public certificate for the Public Registry is located at NIST/XDSb_REG_NIST/nist1.ihe.net.cert.pem in the distribution from Steve.
If you cannot connect to the Public Registry over TLS here are some common reasons:
- http requests non-secure transaction and https requests a secured transaction. The port number is just part of the address to were software exists that might accept your secured/non-secured request.
- The Public Registry is known in the certification collection as nist1.ihe.net. You may have to add this name to your host file with the IP address 129.6.24.109 before your secure software will accept it as valid.
- Specify the endpoint as https://nist1.ihe.net:9443/
If you have to do more than this please let me know so I can update the list.
European TLS
There are updates to both the Public Registry server and the xdstest2 tool.
For xdstest2 tool users, there is now available version 1.15 that is pre-configured with the cert/key for nist2.ihe.net. This will allow testing with your servers. Internal to the scripts delivered with xdstest2, there are changes. In place of the old keystore file which acted as both keystore and truststore, there are now separate keystore.jks and truststore.jks files. The supplied scripts have been updated. The keystore and truststore are shown below.
The keystore looks like:
~/dev/xdstest2tool bill$ keytool -list -v -keystore keystore.jks -storepass changeit
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: xds_server
Creation date: Mar 19, 2008
Entry type: keyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=nist2.ihe.net, OU=318003000900013, L=Paris (75), O=TEST, C=FR
Issuer: OU=AC-CLASSE-4, O=GIP-CPS, C=FR
Serial number: 30303031323035323230373332303030
Valid from: Tue Mar 11 04:32:12 EDT 2008 until: Tue Dec 30 19:00:00 EST 2008
Certificate fingerprints:
MD5: D5:21:D7:2F:0C:80:CD:83:1B:50:BD:5B:50:63:F5:7A
SHA1: 2D:85:43:41:03:D8:86:CF:3E:FF:F8:C4:06:F1:7F:C3:52:04:39:09
Certificate[2]:
Owner: OU=AC-CLASSE-4, O=GIP-CPS, C=FR
Issuer: O=GIP-CPS, C=FR
Serial number: 3030303130303538393739393230303000
Valid from: Mon Nov 12 19:00:00 EST 2001 until: Tue Dec 30 19:00:00 EST 2008
Certificate fingerprints:
MD5: 96:F6:D0:D6:1F:9D:BE:10:49:87:60:9D:E9:95:41:6D
SHA1: 04:EA:FC:58:D5:09:A9:4C:52:10:B2:A0:D1:20:97:D4:DB:BE:33:65
Certificate[3]:
Owner: O=GIP-CPS, C=FR
Issuer: O=GIP-CPS, C=FR
Serial number: 30303031303030343438373333303030
Valid from: Mon Jun 25 20:00:00 EDT 2001 until: Thu Dec 30 19:00:00 EST 2010
Certificate fingerprints:
MD5: 91:B9:A4:5E:EC:FD:95:01:31:34:DB:DE:15:80:82:18
SHA1: F7:35:53:22:EA:4B:80:C7:FF:E2:B4:CB:D4:92:B0:45:45:B9:18:D4
*******************************************
*******************************************
Note that the truststore contains the trustCertEntry for all certificates leading up to the root CA certificate.
For users of the Public Registry, no large changes are necessary. The certs installed there have the same structure as the ones shown in detail above. The cert/key pair prepared for the Public Registry is named incorrectly. Instead of having the name hcxw2k1.nist.gov it has the name hcxw2k1.nist.org. Because of this, you may need to add the following line to your hosts file (/etc/hosts on Unix-like systems):
129.6.24.109 hcxw2k1.nist.org
Syslog Facility
The Public Registry server has a syslog facility to be used with joint XDS/ATNA testing.
- It accepts messages at 129.6.24.109 port 8087
- A browser is available to view your messages here. This browser will only display audit messages sent from the IP address that generated the audit messages.
Audit log message validation is available within the browser. To validate your message:
- Find your message in the browser and select it with the mouse
- Details of your message will appear on the right side of the screen
- Select the Validate link on the top of the right side
- The validation results will be displayed in a separate browser tab or window
NOTE: The validator is limited to the following transactions. Other transactions, when validated, will give a large list of meaningless errors. The validator currently understands the audit log requirements of the following transactions:
- ITI-14
- ITI-15
- ITI-17
- ITI-18
- ITI-41
- ITI-42
- ITI-43
To log validation results for your audit log messages:
- Find your message
- Make sure the validation contains no errors
- Click Right on the Validate link and COPY the link
- Paste the link into a small text file and submit as test evidence in Kudu/Gazelle
Test Data
Test data available in the Public Registry is documented here.
Known Defects and Changes to the XDS Profile (2008-2009 season)
Known Defects and Changes to the XDS Profile (2007-2008 season)
The following defects in the published text have been found. They will be fixed through the formal Change Proposal process. They affect:
- Revision 4.0 of Volume 2 of the ITI Technical Framework (IHE_ITI_TF_4.0_Vol2_FT_2007-08-22.pdf) and
- XDS.b Supplement (IHE_ITI_TF_Supplement_XDS-2.pdf)
- A CP will be submitted to clarify the responsibilities of the Document Repository regarding the handling of the repositoryUniqueId attribute. It is proposed that it be handled like the size, hash, URI attributes. If it is present in the Provide and Register transaction then the Document Repository shall overwrite the attribute.
- A clarification of the semantics behind the GetSubmissionSetAndContents Stored Query has been submitted as a Change Proposal. This clarification points out that the Association objects that link Folders and Documents ARE to be returned by the query. The proposed change to the text can be found here
- Section 4.1.11 - Registry Adaptor - Support Document Replacement section: Document to be replaced must have status = Approved
- XDSDocumentEntry.sourcePatientInfo attribute: Source/Query column shows R8/P (should be R/P) with a footnote saying that certain segments are required, see text for details. Text says single value required but example shows multiple values. Example is correct.
- XDSDocumentEntry.patientId attribute: name should be XDSDocumentEntry.patientId
- XDSSubmissionSet.patientId attribute: uuid should be urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446
- XDSFolder.patientId attribute: uuid should be urn:uuid:f64ffdf0-4b97-4e06-b79f-a52b38ec2f8a
- XDSFolder.codeList attribute: shows single quotes around attribute values - XML specifies they are to be double quotes.
- Change Proposal 241 describes a new configuration of options for the Document Source actor in XDS.a. Its contents were supposed to be reflected in the XDS.b supplement. The new Document Source option configuration applies to both XDS.a and XDS.b. The major change is that now Document Replace operation is optional instead of mandatory for Document Source Actors.
- Section 4.1.13 Error Reporting introduces the new RegistryResponse status code of PartialSuccess without discussing which profiles it may be used in. It is used in the Cross-Community Access (XCA) profile and not in the XDS profile.
- The use of base64 encoding in XDS.a has been poorly understood for a long time. After a review of relevant standards we have found that the relevant standards clearly specify what is acceptable.
- Base 64 encoding IS appropriate (may be generated by the Document Source, must be accepted by the Document Repository) for the Provide and Register transaction
- Base 64 encoding IS NOT allowed in the Retrieve Document (HTTP GET) transaction.
The Provide and Register Document Set and Retrieve Document transactions will be updated with this clarification.
- Change Proposal 267 (word) (new) describes a change to the use of MTOM and MTOM/XOP to align better with common industry practices. Tutorial information and the new specific requirements are documented here. This wiki document has more detail than the formal Change Proposal document for now.
- Change Proposal 28 (word) (integrated into TF) describes how XDS (.a and .b) now uses formal error codes in response messages.
- Change Proposal 117 (word) (integrated into TF) describes how Replace, Append, and Transform (relationships between documents) interact.
- Change Proposal 130 (word) (integrated into TF) allows XDSDocumentEntry.legalAuthenticator and XDSDocumentEntryConfidentialityCode to be multi-valued.
- Change Proposal 145 (word) (integrated into TF) clarifies the Date/Time formatting to be used.
- Change Proposal 164 (word) (integrated into TF) documents how to code Syslog events (ATNA Profile) for XDS.
- Change Proposal 187 (word) (integrated into TF) documents how to insert extra (not specified by XDS) metadata into the Registry.
- Change Proposal 208 (word) (integrated into TF) adds specific labels to metadata elements controlling whether they can/must be single/multi valued.
- Change Proposal 225 (word) (integrated into TF) more clearly states the enforcement rules for unique IDs.
- Change Proposal 226 (word) (integrated into TF) clarifies how OIDs used in unique IDs must be formatted.
- Change Proposal 246 (word) (integrated into TF) documents the move of the metadata tables into their own section.
- Change Proposal 266 (word) (new) documents new error codes beyond what is currently described in the Technical Framework. This list will be added to during the testing season as new needs are identified. These error codes are required at the January 2008 Connectathon.
- Change Proposal 268 (word) (new) clarifies the use of XML namespaces on Association Types in XDS.b. They are required on ALL Association Types.
- Change Proposal 269 (word) (new) clarifies the use of the status value PartialSuccess. It is only to be used in the context of the XCA profile.
- Change Proposal 237 (word) (Approved) defines how Associations may be added to the Registry. One use is for adding an existing Document to an existing Folder.
- (This is either a defect in the Public Registry implementation or a new interpretation of the underlying standard. I am not sure which...yet.)
Some implementers have had problems with the HTTP header SOAPAction. The Public Registry, based on Axis2 libraries, is requiring that the SOAPAction header match the top level request element in order to be valid. This applies only to XDS.a since XDS.b uses WS-Addressing which leads to SOAPAction holding the same value as th Action element of the SOAP Header.
An XDS.a example is
... SOAPAction: "SubmitObjectsRequest" ... ... <soapenv:Body> <rs:SubmitObjectsRequest xmlns:rs="urn:oasis:names:tc:ebxml-regrep:registry:xsd:2.1"> ...
Looking to the relevant standards for guidance produces...
SOAP 1.1 (section 6.1.1) specifies
- The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request.
This would seem to justify the Axis2 interpretation that the SOAPAction match the top level request element. The value "urn:SubmitObjectsRequest" is also valid.
I cannot find other supporting references. If we get through the testing season with this assumption then XDS will updated to reflect this more modern interpretation of SOAPAction. What makes this troubling is that older libraries and tool kits (such as the one use in the old Public Registry implementation) did not implement this restriction.
Open Source
XDS Server, Registry and Repository, can be downloaded in either binary or source versions. Installation instructions and the download elements can be found at http://ihexds.nist.gov:9080/XdsDocs/opensource/. Start by reading the file readme.txt.
