XDS Main Page
From IHEWiki
This site helps with the testing of XDS.a, XDS.b, XCA, and XDR profiles as well as ATNA as it supports these profiles.
The three primary profiles, XDS, XDR, and XCA are sometimes refered to as XD* because it is shorter and easier to type.
Background
This test facility part of a larger effort to test IHE Profiles. Two important links for those interested in the bigger picture are:
Navigating_MESA_Software - which discusses the history and general structure of IHE Profile testing.
Pre-Connectathon/MESA_Software - which lists all the software and tests supported by IHE North America and IHE Europe.
How To Test
This section lists IHE Profiles and actors whose testing is documented on this site. Each section documents tests, tools, and overall approach to testing. This site contains the reference list of tests and test descriptions that are loaded into Gazelle/Kudu.
First a few Perspectives on XDS Testing
Server Testing
If you are testing a server, your server, then you probably have your software running on a development machine that is expecting to receive a network connection from the same machine or another local machine. Since you don't want to deal with firewalls (and corporate policies dealing with firewalls) it would be easier if a test client could be run locally on your development machine to exercise your server. That test client is called xdstest and is discussed more here.
Client Testing
If you are testing your client, a piece of software that expects to initiate a network connection, then you would rather test against a server on the Internet since you don't have to install and maintain the software representing the server. If the communications between your client and the test server on the Internet use standard ports and protocols then your corporate firewall is not going to get in the way of your testing, hopefully. The test server for XDS/XDR/XCA is called the Public Registry Server and will be discussed more below.
Other
There is actually a third category. If you implement a server that accepts a connection and then turns around and initiates a connection to another service. A good XDS example of this is the Document Repository actor which accepts connection requests from a Document Source and then initiates a connection to a Document Registry. This testing pattern is covered by a combination of the Server Testing and Client Testing procedures alluded to above.
Document Consumer (XDS.a and XDS.b)
All transactions for this actor are tested against the Public Registry Server. Generic WS endpoints are documented here. Individual tests may define specific required endpoints be used.
The Document Consumer actor is a client so it is tested against the Public Registry Server, specifically the Document Registry and Document Repository implementations.
Transaction specific tests are documented:
| Transaction | Tests |
|---|---|
| Query (SQL) (XDS.a) | tests |
| Stored Query (XDS.a) | tests |
| Retrieve (XDS.a) | tests |
| Stored Query (XDS.b) | tests |
| Retrieve Document Set (XDS.b) | tests |
All transactions are required to generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.
Document Source (XDS.a and XDS.b)
The Document Source actor is a client so it is tested against the Public Registry Server, specifically the Document Repository implementation. Some of the tests defined below require that the Document Source actor be bound with a Document Consumer actor, allowing queries. Most of the Life Cycle option and Folder option tests are like this. A specific testing event may only require a subset of these tests to be performed.
Generic WS endpoints are documented here. Individual tests may define specific required endpoints be used.
Transaction specific tests are documented:
| Transaction | Tests | Tools |
|---|---|---|
| Provide and Register (XDS.a) | tests | Public Registry Server |
| Provide and Register.b (XDS.b) | tests | Public Registry Server |
All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.
Document Registry (XDS.a and XDS.b)
All transactions for this actor are tested using the downloaded XDSToolkit and Testkit. Transaction specific tests are documented:
| Transaction | Tests |
|---|---|
| Register (XDS.a) | here |
| Register.b (XDS.b) | here |
| Stored Query (XDS.a) | here |
| Stored Query (XDS.b) | here |
| SQL Query (XDS.a) | here |
All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.
Document Repository (XDS.a and XDS.b)
Transactions for this actor are tested using both the downloaded XDSToolkit and Testkit as well as the Public Registry Server. Transaction specific tests are documented:
| Transaction | Tests |
|---|---|
| Provide and Register (XDS.a) and Register (XDS.a) (together) | here |
| Provide and Register.b (XDS.b) and Register.b (XDS.b) (together) | here |
| Retrieve (XDS.a) | here |
| Retrieve Document Set (XDS.b) | here |
Submissions are tested by:
- Configuring the Document Repository under test to forward to the Document Registry actor on the Public Registry Server
- Using xdstest, submit a Provide and Register to the Repository under test, this results in a Register transaction to the Document Registry
- Using xdstest, query the Document Registry to get the deposited metadata to evaluate it
Retrieves are tested by
- Configuring the Document Repository under test to forward to the Document Registry actor on the Public Registry Server
- Using xdstest, submit a Provide and Register to the Repository under test, this results in a Register transaction to the Document Registry
- Using xdstest, query the Document Registry to get the deposited metadata
- Using xdstest, retrieve and evaluate the document from the Document Repository
All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.
Document Source (XDR)
The Document Source actor is a client so it is tested against the Public Registry Server, specifically the Document Recipient implementation. The Document Source actor in XDR is different from the Document Source actor in XDS in that it cannot be bound to a Document Consumer actor giving it the ability to perform Stored Query or Retrieve Document Set transactions. Thus, the following operations, normal for a Document Source in XDS cannot be performed by a Document Source in XDR:
- Submit Document Replace/Append/Transform
- Add to an existing Folder
The Document Recipient implementation on the Public Registry Server performs the following duties:
- Validate that the submission is valid by the rules of XDR (above list)
- Forward submission on to the Document Repository/Registry implementation for local storage (where more basic XDS validations are performed).
Because the XDR submissions are forwarded on to the XDS Repository and Registry, they can be:
- Queried via Stored Query transaction and retrieved by Retrieve Document Set transaction even though this behavior is beyond the scope of XDR.
- More importantly, these XDR submissions can be found in the Test Log just like XDS submissions which aids in diagnosing problems during testing.
Generic WS endpoints will be documented soon. Individual tests may define specific required endpoints be used.
The only transaction used in XDR is Provide and Register Document Set which requires MTOM/XOP web service formating for both request and response (example). Examples of metadata contents, contents of the RegistryObjectList element, are:
- Submission of one DocumentEntry (discussion, [http: example])
- Submission of two DocumentEntries (discussion, [http: example])
- Submission of a Folder containing a single DocumentEntry (discussion, [http: example])
There is a page in the IHE Implementation Guide discussing XDR that can be found here.
Transaction specific tests are documented:
| Transaction | Tests | Tools |
|---|---|---|
| Provide and Register.b (XDR) | here | Public Registry Server |
All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.
Document Recipient (XDR)
Transactions for this actor are tested using both the downloaded xdstoolkit and testkit. Transaction specific tests are documented:
| Transaction | Tests |
|---|---|
| Provide and Register.b (XDR) | here |
Submissions are tested by:
- Using xdstest, submit a Provide and Register transaction to the Document Recipient under test
There is a page in the IHE Implementation Guide discussing XDR that can be found here.
Initiating Gateway (XCA)
All transactions for this actor are tested against the Public Registry Server. Generic WS endpoints are documented here. Individual tests may define specific required endpoints be used. Transaction specific tests are documented:
| Transaction | Tests |
|---|---|
| Cross-Community Query | here |
| Cross-Community Retrieve | here |
All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.
Responding Gateway (XCA)
All transactions for this actor are tested using the downloaded xdstoolkit and testkit. Transaction specific tests are documented:
| Transaction | Tests |
|---|---|
| Cross-Community Query | here |
| Cross-Community Retrieve | here |
All transactions are required generate audit messages to the Audit Record Repository. Individual tests for this requirement are documented here.
Secure Node (ATNA)
The test collection for each of the above transactions includes requirements to test the transaction over a TLS protected connection as well as demonstrating the generation of appropriate audit messages.
Tool Overviews
For the testing of XDS/XDR/XCA there are basically two tools, the Public Registry Server and the XDS Toolkit. The Public Registry server is good for testing client software (software that starts by initiating a network connection). This server/service is available on the Internet year-round. The XDS Toolkit is a downloadable toolkit for testing your own servers (software that starts by accepting an incoming connection). This section gives an overview of these tools.
Public Registry Server
Internet site hosting reference implementations of:
- Document Registry (XDS.a and XDS.b)
- Document Repository (XDS.a and XDS.b)
- Document Recipient (XDR)
- Responding Gateway (XCA)
- Audit Record Repository (ATNA) (as it applies to XDS/XDR/XCA only)
The Public Registry Server is itself the largest tool used in testing XDS/XDR/XCA. The key thing to know about this tool is the collection of Web Service Endpoints. They are documented here.
The rest of the tools, listed below have more technical documentation that can be found here.
Test Log
Database on the Public Register server that logs all events to the Document Registry, Document Repository, Document Recipient, and Responding Gateway implementations. The Test Log Browser (discussed here) can be used to browse your entries to obtain detailed error status (sometimes beyond what is returned in error codes and error messages). For XDS/XDR/XCA tests requiring interaction with the Public Registry server, the Test Log Browser allows downloading of EVS files, small text files that document your test results. For testing events managed by Kudu/Gazelle, these EVS files are uploaded as proof of completion of the tests. The Test Log Browser is available here.
XDS Toolkit
A downloadable collection of test tools. This toolkit, along with the testkit, are needed to test Document Registry, Document Repository, Document Recipient and Responding Gateway actor implementations. This allows these actors to be tested on a development machine behind the implementer's firewall. A copy of the testkit is included in this download. Download is available from here.
Testkit
A downloadable collection of test scripts that are executed by the tool xdstest. Each test is labeled with a test number (like 11900). Tests for XDS/XDR/XCA are documented here.
xdstest
A command line tool used to test Document Registry, Document Repository, and Responding Gateway, and Document Recipient actors. Xdstest is a language interpreter for the test scripts contained in the testkit. Xdstest is part of the XDS Toolkit.
Audit Log
The Public Registry Server offers an Audit Record Repository (ARR) actor implementation for testing the auditing requirements of IHE actors. This service includes a browser for viewing your audit records. The Audit Log Browser is available here.
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
Where to ask questions
We have a mailing list dedicated to XDS/XDR/XCA (and related profile) implementation and 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.
Testing
Test Documentation
- a table of all the XDS/XDR/XCA tests indexed by the XDS transaction they support. Includes links to the documentation for each test. This link always points to the current year/season. This table is used to load Gazelle/Kudu so if you find discrepancies please let me know.
Detailed Test Descriptions/Instructions for the 2009/2010 season
- detailed description of all the tests with instructions for executing. You can look directly here if you know a test number. If you want to look up a test by actor or profile use the link in the previous section.
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.
Rules for submitting results to Gazelle/Kudu
There are two kinds of result files used in XDS/XDR/XCA testing. Tests executed with the XDSTookit/xdstest are always named log.xml. A single test, such as 11733, can have multiple sections (multiple testplan.xml files) and therefore generate multiple log.xml files. To get credit for your testing, these files must be uploaded into Gazelle/Kudu for the correct test. The evaluation is done by software so you must follow some simple rules or the test will not get labeled as passed.
- Upload the logs to the correct test (yes, our software does check)
- Do not upload last year's log files (see above)
- If a test has multiple sections and generates multiple log files, collect them in a ZIP file for upload. The file names inside the ZIP file are not important, just the content in the files.
- If a test has only a single section and therefore only generates a single log.xml file, it can be uploaded as is or ZIPed.
- If you submit logs for tests that failed, don't expect credit (yes, I did have to say that)
The second type of test result is generated by the Public Registry Server for tests that are run against that server. The Test Log Browser and Syslog Browser offer a link to download an EVS file. EVS stands for External Validation Service. These are small (10 lines or so) XML files that document what was accomplished and offer a link back into the log database (for validation). To get credit for this style of test:
- Run the test against the Public Registry Server
- Find your results in the Test Log Browser or Syslog Browser
- Click on the EVS link (right side - top) to download this small file
- Upload the file into Gazelle/Kudu
Testing Tools
- Renamed to just xdstest, this is a command line tool that acts as Document Source, Document Consumer, Document Repository or 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 that operate on the Public Registry Server. 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. Test results files (aka EVS files) can be download for subsequent upload into Gazelle/Kudu to document sucessful testing during Pre-Connectation (aka MESA) testing.
- 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. Test results files (aka EVS files) can be download for subsequent upload into Gazelle/Kudu to document sucessful testing during Pre-Connectation (aka MESA) testing.
- 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 directory containing scripts for initializing Registry and Repository actors for other tests; tests directory which are the tests; and examples directory 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 Gazelle/Kudu. Individual test documentation can be found on the wiki page here. A FAQ for this tool is maintained here.
- Facilities for testing asynchronous interactions with XDS.b and XCA. A FAQ is maintained here.
Public Registry Server Configuration
The Public Registry is a server maintained on the Internet and is generally always available for private or IHE sponsored testing.
It resides at ihexds.nist.gov (129.6.24.109).
Configuration
Affinity Domain Configuration (XML)
- that defines the Public Registry Affinity Domain configuration. This includes definitions of acceptable codes, mime types etc. The Metadata Validator tool (web page) is available for you to manually test your metadata. The same validator is used to check every metadata submission to the Public Registry (ProvideAndRegisterDocumentSet and RegisterDocumentSet transactions). 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.
Test Event Configuration
The proper endpoint to use for testing is determined by the following:
- The service (Registry vs. Repository vs. a specialty service designated for a specific test)
- Which version of the Technical Framework you are testing against
- tf5 - Technical Framework version 5
- tf6 - Technical Framework version 6
- Which testing event you are preparing for. Each event issues its own collection of certificates for TLS so using the proper endpoint will give you access using your issued certificate.
In the tables below, these issues are reduced to three 'variables':
- YEAR
- which really means the version of the Technical Framework (tf5 vs tf6)
- EVENT
- the non-TLS port number to use
- SEVENT
- the TLS (secure) port number to use
Important URLs / WS Endpoints
Event Configurations
| Event Name | YEAR | EVENT | SEVENT | Available |
|---|---|---|---|---|
| North American Connectathon in Chicago in Feburary 2009 | tf5 | 9080 | Yes | |
| European Connectathon in Chicago in April 2009 | tf5 | 9080 | 9001 | Yes |
| North American Connectathon in Chicago in Feburary 2010 | tf6 | 9080 | 9085 | Yes |
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 |
| Multi-Patient 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 |
| Multi-Patient 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
TLS
The Public Registry Server and the XDSToolkit support only two cryptographic cyphers for TLS:
- TLS_RSA_WITH_AES_128_CBC_SHA
- SSL_RSA_WITH_3DES_EDE_CBC_SHA
We impose this limitation for a couple of reasons:
- It slightly simplifies the debugging of TLS connection problems since fewer cyphers are exchanged (yielding smaller log files)
- We have not yet found a system that did not have one of these available in their default set (if necessary we will add to this list in the future)
North American and European Connectathons typically utilize different style certificates. North America usually issues self-signed certs while Europe usually employs a certificate authority. Usually the issued certificates are valid for a period of one year (until next year's testing season). A TLS-enabled port is available for each certificate set.
Updated certificates are loaded onto the Public Registry Server each season. Likewise, a new version of the XDS Toolkit is issued each season containing the new certificates.
Syslog Facility
The Public Registry server has a syslog facility to be used with joint XDS/ATNA testing.
- It accepts syslog messages at ihexds.nist.gov (129.6.24.109) port 8087 on UDP.
- A browser (here) is available to view your audit messages. This browser will only display your audit messages to you. It does this by sensing your IP address and only displaying entries generated from that IP.
The browser includes a validator that evaluates the content of a syslog message against the requirements published in the Technical Framework. To validate one of your messages:
- 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/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
A mechanism for you to get credit for your audit message during Pre-Connectathon testing (also called MESA testing) will be published soon.
Test Data
Test data available in the Public Registry is documented here.
Understanding EVS
XDS and related tests require the vendor to upload evidence files to Kudu/Gazelle for evaluation. Successful evaluation results in tests being marked as passed. This section describes the process of evaluation and how to use it.
Tests that can be auto-evaluated have a button NIST Validation on the Connectathon Manager's Mesa Log Return page. It is found in the Logs column. Pushing this button does:
- The uploaded log files are bundled into an EVS request to the NIST Public Registry Server.
- The result of this request is displayed as XML at the top of the page.
- If the result is Success then the relevant test is marked Ok.
- If the result is Failure then the ugly XML displayed must be scanned for the first <error> element. The text content of this element is the error message.
- For Connectathon Managers, this error text should be evaluated to see if it is a tooling problem or a vendor testing problem:
- If the error text looks like Validating test 11995, which contains section eval but no log for that test/section was submitted, found [11994/rplc, 11994/xfrm, 11994/submit, 11994/eval] instead. then the problem belongs to the vendor.
- Other typical vendor mistakes are wrong endpoint used on the Public Registry server and results include tests that failed
- Most other error messages are really tooling problems
- Vendor error messages should be copied into the Comment box and the test marked as Failed
- Tooling problem messages should come back to me to investigate
- There is one class of tooling problem messages that should go back to the vendors. The Java platform I use has a well known bug decoding some ZIP files. This occurs if the ZIP compression uses a particular type of coding. The error indicates that the tool cannot decode the ZIP file. This seems to occur in one out of twenty ZIP files. In this case all that can be done is for the vendor to remove the ZIP file from the upload area and in its place upload the individual log.xml files. They will need unique names (within their set of files) but the file names are not important to validation. When the Java platform posts an update that fixes this bug this error will no longer appear. Error messages that are shown because of this bug are:
- EvsWrapper#getLogsByTest: found 2 Test elements in log, the testlog file must be corrupted
Open Source
The code for the Public Registry Server is Open Source See http://ihexds.nist.gov for details.
