XCA Onion References

Because XCA builds upon a large body of prior work it seems like an onion of specifications, where each layer of specification contains only a thin layer of content and then refers to the lower layer. This section lays out the onion and attempts to link directly into the sections being referenced. It is an in trial section since the direct referencing is a pilot and not fully tested yet.

The XCA Onion looks like the following:

XCA Profile Specification - XCA Supplement Vol. 1 Section 18 page 14
- Cross Gateway Query - XCA Supplement Vol. 1 Section 3.38 page 36
  - Registry Stored Query - ITI TF Vol. 2a Section 3.18 page 94
    - XDS Metdata Model - ITI TF Vol. 3 Section 4.1 page 3, 13 4.1.7 page 13, 4.1.8 page 31
    - ebRS
- Cross Gateway Retrieve - XCA Supplement Vol. 1 Section 3.39 page 42
  - Retrieve Document Set - ITI TF Vol. 2b Section 3.43 page 115

Updates from 2008

All of the following changes have been resolved and integrated into the latest versions

After publication of the August 2007 Trial Implementation version of Cross Community Access (XCA) profile several issues have come to light. These issues are documented in Change Proposals (CPs) which will be completed during the year and integrated in August 2008. Prior to August 2008 this page will list the issues and their expected resolution, both short term and long term.

Typos

CP 256 contains a couple of small typos. One of which is to change the name to be grammatically correct, from Cross Community to Cross-Community. Please communicate any further typos discovered in the XCA profile to the CP auther for inclusion in this CP. The current version of the CP can be accessed in the Assigned directory.

Missing Web Services protocol information

CP 257 contains the missing web services protocol information (WSDL and examples). Please use this information for your implementations. For more detail access CP 257 in the Assigned directory. The example files and WSDL are also available in the SupportMaterial directory.

Support of SOAP 1.1 and 1.2

The Web Services protocol section of a profile describes support for SOAP version. XCA desires to be consistent with XDS.b transactions. CP 265 addresses the lack of clarity on requirements for support for SOAP versions. XDS.b suggests SOAP 1.2 is "required" and SOAP 1.1 is "optional" but it is not clear what that means. For the short term we expect the server side of the transaction to support both, and client chooses. Because of other considerations, this translates into requiring the Responding Gateway to support both SOAP 1.1 and SOAP 1.2 from the same URL. We will re-assess this requirement based on feedback from implementation and connectathon testing.

For more detail access CP 265 in the Assigned directory.

Implied assumption of Responding Gateway URLs

The design of XCA has an unstated assumption that a Responding Gateway will use the same URL for responding to Cross Gateway Retrieve transactions as it does for Cross Gateway Query transactions. The homeCommunityId attribute is associated with the url that responded to a Cross Gateway Query. This association is used in subsequent requests to determine which url to use to communicate to get more detailed information regarding elements returned in the previous request. This assumes that the same url will be used for subsequent query requests as well as retrieve requests. This assumption is not stated clearly. It poses a restriction on the design of a Responding Gateway that should be reviewed to verify that it is reasonable. Also, this mapping does not handle movement of service or changes in url values.

For this year we will require that Responding Gateways support query and retrieve from the same URL. CP 258 documents this issue. The long term resolution of this problem is not defined yet but will include either an update to the document to make the requirement clear or a change in the requirement.

The latest version of the CP can be accessed in the Assigned directory.

Actions by Initiating Gateway when homeCommunityID is missing

The supplement does not clearly state what the expectations of the Initiating Gateway are when it receives a response from a Responding Gateway which does not appropriately specify homeCommunityId. Presumably an error is reflected to the Document Consumer regarding this situation, but exactly what kind of error? CP 270 documents this issue.

For this year the Initiating Gateway will be expected to return elements which contain home and return an error for elements that do not contain home. We request feedback from implementors on this subject and will consider it as part of the final resolution after 2008 connectathon.

The latest version of CP 270 can be accessed in the Assigned directory.

One homeCommunityId value per Responding Gateway URL

The supplement expects that a Responding Gateway will always return "its" homeCommunityId, and that there will be only one URL that maps to any unique homeCommunityId. This needs to be clarified in the supplement. Also, we will be considering whether this restriction in the long term is appropriate. A CP has been submitted, currently in Incoming, to consider this situation and clarify the supplement text on this regard.

For this year it can be assumed by Initiating Gateway implementations that any particular Responding Gateway will return one homeCommunityId, and if a homeCommunityId is received from a "new" URL that value overlays any previous value that was saved.

Do we really need new transactions for XCA

It has been pointed out that the Cross Gateway Query and Cross Gateway Retrieve are nearly identical to the Registry Stored Query and Retrieve Document Set. Does it really make sense to keep these as separate transactions? A CP has been submitted, currently in Incoming, to initiate discussion of this question.

For this year we will consider these separate transactions.

ATNA Logging Events For XCA transaction

The supplement says: the auditing of the Cross Gateway Query transaction should be "identical" to the Registry Stored Query transaction (from a Document Consumer or a Document Registry).

This means:

Syslog rules documented for XDS here apply
Small changes have been made to these rules to adapt them to XCA. Download the text of the Change Proposal from here

The Technical Framework is being updated to reflect these changes. The appropriate Change Proposals have already been approved.

XCA Implementation

Contents