Issues for Mailing list of the Identity Cross-Reference Service and Retrieve, Locate and Update Service RTF
To comment on any of these issues, send email to ixs-rlus-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 15895: EISMetaDataInterface.wsdl
Issue 15896: swpEISAdminEditorInterface.wsdl
Issue 16300: Error in specification document and in machine-consumable files
Issue 17121: The content of the specification doc is the IXS specification and not RLUS
Issue 17122: machine-consumable files are the same as in beta 2 version
Issue 17123: more serious inconsistences in machine-consumable files
Issue 17124: RLUSExpression.xsd is declared, in RLUSType.xsd, with the old intel namespace
Issue 17125: Reintroduce generic wsdl
Issue 15895: EISMetaDataInterface.wsdl (ixs-rlus-rtf)
Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary:
EISMetaDataInterface.wsdl opens in Visual Web Developer 2008 with 90 warnings and 26 messages. The well-formedness of this WSDL file needs to be investigated and corrections applied as necessary.
Resolution: Correct the errors in the WSDL.
Revised Text: Apply the following diff file in an XML editor, or substitute the IXSMetaDataInterface.wsdl delivered as part of dtc/2012-09-06.
14a15
> <xs:element name="createSemanticSignifier" type="ixs:createSemanticSignifier"/>
24a26,27
> <xs:element name="createSemanticSignifierResponse"
> type="ixs:createSemanticSignifierResponse"/>
29a33
> <xs:element name="findSemanticSignifier" type="ixs:findSemanticSignifier"/>
39a44,45
> <xs:element name="findSemanticSignifierResponse"
> type="ixs:findSemanticSignifierResponse"/>
46a53
> <xs:element name="updateSemanticSignifier" type="ixs:updateSemanticSignifier"/>
56a64,65
> <xs:element name="updateSemanticSignifierResponse"
> type="ixs:updateSemanticSignifierResponse"/>
60c69
< <xs:element name="semanticSignifier" type="ixs:ixsSemanticSignifier"
---
> <xs:element name="semanticSignifier" type="ixs:ixsSemanticSignifierDefinition"
63a73
> <xs:element name="listSemanticSignifiers" type="ixs:listSemanticSignifiers"/>
74a85,86
> <xs:element name="listSemanticSignifiersResponse"
> type="ixs:listSemanticSignifiersResponse"/>
81a94
> <xs:element name="listDomains" type="ixs:listDomains"/>
84a98
> <xs:element name="listDomainsResponse" type="ixs:listDomainsResponse"/>
91a106
> <xs:element name="listConformanceProfiles" type="ixs:listConformanceProfiles"/>
95c110,112
< <xs:complexType name="listConformanceProfilesRessponse">
---
> <xs:element name="listConformanceProfilesResponse"
> type="ixs:listConformanceProfilesResponse"/>
> <xs:complexType name="listConformanceProfilesResponse">
140a158,191
> <xs:complexType name="ixsState">
> <xs:sequence>
> <xs:element name="ixsMediatingIdStartState" type="xs:boolean">
> <xs:annotation>
> <xs:documentation> </xs:documentation>
> </xs:annotation>
> </xs:element>
> <xs:element name="inputSourceIdStartState" type="xs:boolean">
> <xs:annotation>
> <xs:documentation> </xs:documentation>
> </xs:annotation>
> </xs:element>
> <xs:element name="inputSourceOtherIdStartState" type="xs:boolean">
> <xs:annotation>
> <xs:documentation> </xs:documentation>
> </xs:annotation>
> </xs:element>
> <xs:element name="otherSourceAnyIdStartState" type="xs:boolean">
> <xs:annotation>
> <xs:documentation> </xs:documentation>
> </xs:annotation>
> </xs:element>
> <xs:element name="ixsMediatingIdEndState" type="xs:boolean">
> <xs:annotation>
> <xs:documentation> </xs:documentation>
> </xs:annotation>
> </xs:element>
> <xs:element name="inputSourceIdEndState" type="xs:boolean">
> <xs:annotation>
> <xs:documentation> </xs:documentation>
> </xs:annotation>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
212a264,266
> <wsdl:message name="createSemanticSignifierResponse">
> <wsdl:part name="response" element="ixs:createSemanticSignifierResponse"/>
> </wsdl:message>
215a270,272
> <wsdl:message name="findSemanticSignifierResponse">
> <wsdl:part name="response" element="ixs:findSemanticSignifierResponse"/>
> </wsdl:message>
218a276,278
> <wsdl:message name="updateSemanticSignifierResponse">
> <wsdl:part name="response" element="ixs:updateSemanticSignifierResponse"/>
> </wsdl:message>
221a282,284
> <wsdl:message name="listSemanticSignifiersResponse">
> <wsdl:part name="response" element="ixs:listSemanticSignifiersResponse"/>
> </wsdl:message>
224a288,290
> <wsdl:message name="listDomainsResponse">
> <wsdl:part name="response" element="ixs:listDomainsResponse"/>
> </wsdl:message>
227a294,296
> <wsdl:message name="listConformanceProfilesResponse">
> <wsdl:part name="response" element="ixs:listConformanceProfilesResponse"/>
> </wsdl:message>
268c337,338
< <wsdl:binding name="IXSAdminEditorInterfacePortBinding" type="ixs:IXSAdminEditorInterface">
---
>
> <wsdl:binding name="IXSMetaDataInterfacePortBinding" type="ixs:IXSMetaDataInterface">
269a340,348
> <!-- <wsdl:operation name="createSemanticSignifier">
> <soap:operation soapAction="urn:createSemanticSignifier" style="document"/>
> <wsdl:input>
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output>
> <soap:body use="literal"/>
> </wsdl:output>
> </wsdl:operation> -->
271a351,395
> <wsdl:input>
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output>
> <soap:body use="literal"/>
> </wsdl:output>
> </wsdl:operation>
> <wsdl:operation name="findSemanticSignifier">
> <soap:operation soapAction="urn:findSemanticSignifier" style="document"/>
> <wsdl:input>
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output>
> <soap:body use="literal"/>
> </wsdl:output>
> </wsdl:operation>
> <wsdl:operation name="updateSemanticSignifier">
> <soap:operation soapAction="urn:updateSemanticSignifier" style="document"/>
> <wsdl:input>
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output>
> <soap:body use="literal"/>
> </wsdl:output>
> </wsdl:operation>
> <wsdl:operation name="listSemanticSignifiers">
> <soap:operation soapAction="urn:listSemanticSignifier" style="document"/>
> <wsdl:input>
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output>
> <soap:body use="literal"/>
> </wsdl:output>
> </wsdl:operation>
> <wsdl:operation name="listDomains">
> <soap:operation soapAction="urn:listDomains" style="document"/>
> <wsdl:input>
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output>
> <soap:body use="literal"/>
> </wsdl:output>
> </wsdl:operation>
> <wsdl:operation name="listConformanceProfiles">
> <soap:operation soapAction="urn:listConformanceProfiles" style="document"/>
Actions taken:
December 13, 2010: received issue
April 1, 2013: closed issue
Discussion:
Issue 15896: swpEISAdminEditorInterface.wsdl (ixs-rlus-rtf)
Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary: swpEISAdminEditorInterface.wsdl needs to be refactored to account for the update of the specification name to IXS.
Resolution: swpEISAdminEditorInterface.wsdl needs to be refactored to account for the update of the specification name to IXS.
Revised Text: Apply the following diff file in an XML editor, or substitute the IXSAdminnterface.wsdl delivered as part of dtc/2012-09-06.
Revised Text:
15a16
> <xs:element name="mergeEntities" type="ixs:mergeEntities"/>
55a57
> <xs:element name="mergeEntitiesResponse" type="ixs:mergeEntitiesResponse"/>
60a63
> <xs:element name="unMergeEntities" type="ixs:unMergeEntities"/>
100a104
> <xs:element name="unMergeEntitiesResponse" type="ixs:unMergeEntitiesResponse"/>
105a110
> <xs:element name="linkEntities" type="ixs:linkEntities"/>
153a159
> <xs:element name="linkEntitiesResponse" type="ixs:linkEntitiesResponse"/>
158a165
> <xs:element name="unlinkEntities" type="ixs:unlinkEntities"/>
204a212
> <xs:element name="unlinkEntitiesResponse" type="ixs:unlinkEntitiesResponse"/>
210,292c218
< <!-- <xs:complexType name="activateEntity">
< <xs:sequence>
< <xs:element name="entityTypeName" type="xs:string" minOccurs="1">
< <xs:annotation>
< <xs:documentation>
< The EntityTypeName (e.g., PERSON) for the type of Identity associated with the entityId and sourceId
< </xs:documentation>
< </xs:annotation>
< </xs:element>
< <xs:element name="entityId" type="xs:string" minOccurs="1">
< <xs:annotation>
< <xs:documentation>
< A GUID or alphanumeric ID which uniquely identifies the data representing the
< canonical record in the underlying local system
< </xs:documentation>
< </xs:annotation>
< </xs:element>
< <xs:element name="sourceId" type="xs:string" minOccurs="1">
< <xs:annotation>
< <xs:documentation>
< A GUID or alphanumeric ID which uniquely identifies the local system and its associated CBR.
< Note: A HIN is considered a local system by the IXS service.
< </xs:documentation>
< </xs:annotation>
< </xs:element>
< <xs:element name="reasonCode" type="xs:string" minOccurs="0">
< <xs:annotation>
< <xs:documentation>
< An alphanumeric code used to describe why a IXS identity was activated.
< Specific meanings of specific codes is implementation dependent and this
< is intended for use in a human readable display
< </xs:documentation>
< </xs:annotation>
< </xs:element>
< </xs:sequence>
< </xs:complexType>
< <xs:complexType name="activateEntityResponse">
< <xs:sequence>
< <xs:element name="return" type="ixs:ixsStatus" minOccurs="0"/>
< </xs:sequence>
< </xs:complexType>
< <xs:complexType name="deactivateEntity">
< <xs:sequence>
< <xs:element name="entityTypeName" type="xs:string" minOccurs="1">
< <xs:annotation>
< <xs:documentation>
< The EntityTypeName (e.g., PERSON) for the type of Identity associated with the entityId and sourceId
< </xs:documentation>
< </xs:annotation>
< </xs:element>
< <xs:element name="entityId" type="xs:string" minOccurs="1">
< <xs:annotation>
< <xs:documentation>
< A GUID or alphanumeric ID which uniquely identifies the data representing the
< canonical record in the underlying local system
< </xs:documentation>
< </xs:annotation>
< </xs:element>
< <xs:element name="sourceId" type="xs:string" minOccurs="1">
< <xs:annotation>
< <xs:documentation>
< A GUID or alphanumeric ID which uniquely identifies the local system and its associated CBR.
< Note: A HIN is considered a local system by the IXS service.
< </xs:documentation>
< </xs:annotation>
< </xs:element>
< <xs:element name="reasonCode" type="xs:string" minOccurs="0">
< <xs:annotation>
< <xs:documentation>
< An alphanumeric code used to describe why a IXS identity was Deactivated.
< Specific meanings of specific codes is implementation dependent and this
< is intended for use in a human readable display
< </xs:documentation>
< </xs:annotation>
< </xs:element>
< </xs:sequence>
< </xs:complexType>
< <xs:complexType name="deactivateEntityResponse">
< <xs:sequence>
< <xs:element name="return" type="ixs:ixsStatus" minOccurs="0"/>
< </xs:sequence>
< </xs:complexType>
< -->
---
>
414,426c340
< <!-- <wsdl:message name="activateEntity">
< <wsdl:part name="request" element="ixs:activateEntity"/>
< </wsdl:message>
< <wsdl:message name="activateEntityResponse">
< <wsdl:part name="response" element="ixs:activateEntityResponse"/>
< </wsdl:message>
< <wsdl:message name="deactivateEntity">
< <wsdl:part name="request" element="ixs:deactivateEntity"/>
< </wsdl:message>
< <wsdl:message name="deactivateEntityResponse">
< <wsdl:part name="response" element="ixs:deactivateEntityResponse"/>
< </wsdl:message>
< -->
---
>
462,483c376
< <wsdl:operation name="activateEntity">
< <wsdl:documentation> This operation marks the record as “active” in the IXS repository,
< effectively marking it as logically un-deleted. Status Conditions Returned Code
< Severity Message 1014 Info Entity successfully activated 2007 Error Entity
< Referenced does not exist in the IXS 2002 Error The Trait identified by ‘%1’ does
< not exist in the IXS 2022 Error Reason Code is not in a valid format or does not
< exist in the IXS 2009 Error The Entity Type identified by ‘%1’ does not exist in the
< IXS </wsdl:documentation>
< <wsdl:input message="ixs:activateEntity"/>
< <wsdl:output message="ixs:activateEntityResponse"/>
< </wsdl:operation>
< <wsdl:operation name="deactivateEntity">
< <wsdl:documentation> This operation marks the record as “inactive” in the IXS
< repository, effectively marking it available for Get() or List() operations at the
< entity level but not from the IXS repository. Status Conditions Returned Code
< Severity Message 1015 Info Entity successfully deactivated 2002 Error The Trait
< identified by ‘%1’ does not exist in the IXS 2007 Error Entity Referenced does not
< exist in the IXS 2022 Error Reason Code is not in a valid format or does not exist
< in the IXS 2009 Error The Entity Type identified by ‘%1’ does not exist in the IXS </wsdl:documentation>
< <wsdl:input message="ixs:deactivateEntity"/>
< <wsdl:output message="ixs:deactivateEntityResponse"/>
< </wsdl:operation>
---
>
536,553c429
< <!-- <wsdl:operation name="activateEntity">
< <soap:operation soapAction="urn:activateEntity" style="document"/>
< <wsdl:input>
< <soap:body use="literal"/>
< </wsdl:input>
< <wsdl:output>
< <soap:body use="literal"/>
< </wsdl:output>
< </wsdl:operation>
< <wsdl:operation name="deactivateEntity">
< <soap:operation soapAction="urn:deactivateEntity" style="document"/>
< <wsdl:input>
< <soap:body use="literal"/>
< </wsdl:input>
< <wsdl:output>
< <soap:body use="literal"/>
< </wsdl:output>
< </wsdl:operation>-->
---
>
Actions taken:
December 13, 2010: received issue
April 1, 2013: closed issue
Discussion:
Issue 16300: Error in specification document and in machine-consumable files (ixs-rlus-rtf)
Click here for this issue's archive.
Source: INVITALIA (Mr. Stefano Lotti, slotti(at)invitalia.it)
Nature: Revision
Severity: Critical
Summary: 1. The content of the specification doc is the IXS specification and not RLUS. Nothing of the RLUS spec (beta1 and 2) is in the document except some titles.
Solution: make use of beta 2 specification doc (if a new document does not exist)
2. The machine-consumable files are the same as in beta 2 version. In this version there are some serious inconsistences:
- The wsdl element "RLUSXMLSearch" does not exist in RLUSTypes.xsd. The correct element should be "RLUSSearchStruct" (or the RLUSTypes.xsd file uploaded is wrong). The issue affects get() list() and locate() operations.
- The RLUSTypes is declared as xmlns:RLUStypes="urn:RLUStypes.hssp.intel.com" and xmlns:xsd="http://www.omg.org/spec/RLUS/201012/RLUStypes" consequently some inconsistences arises in wsdls
- RLUSExpression.xsd is declared, in RLUSType.xsd, with the old intel namespace
Solution: correct wsdls
3. The "generic" wsdl (present in beta1) is missed. The generic wsdl should be the normative file. The specialized wsdls (order and patient) should be only examples
Solution: Reintroduce generic wsdl
4. There are misalignments among specification document and the wsdls:
- The specification document (obviously I'm referring to beta 1/2 version) consider only the operation specified in beta 1 wsdls. However the beta2 wsdls includes new operations (findDuplicateDefinitions(), linkRecords(), unlinkRecords(), mergeRecords(), unMergeRecords(), inactivateRecord(), reactivateRecord(), cancelOrder(), detectDuplicateOrder() ). For the new operations there is some minor issue of naming style, it's not consistent with the originals operations from beta 1.
- Note: some new operations refer to a specific scenario (cancelOrder(), detectDuplicateOrder() ). However in RLUS is very relevant the separation of concerns between operations and Semantic Signifier. This aspect it’s relevant in RTF work. In general I think that the semantic aspects should be conveyed only in the Semantic Signifier and not in in other elements of the wsdl (this consideration is not an element of the urgent fix).
Solution: The normative "generic" wsdl must be consistent with the specification document. The new operations can be considered (and documented in wsdls) as “experimental” and included only in wsdls specific example (order, patient).
Some of the new interesting feature, possibly, will be included the new HL7 SFM in the meantime.
Resolution: Disposition: See issues 17121, 17122, 17123, 17124, 17125, 17126 for disposition
Revised Text:
Actions taken:
May 30, 2011: received issue
April 1, 2013: closed issue
Discussion: This issue was parsed into 6 new issues – 17121, 17122, 17123, 17124, 17125, 17126. Five of these issues were resolved. 17126 was deferred due to lack of expertise on the RTF.
Issue 17121: The content of the specification doc is the IXS specification and not RLUS (ixs-rlus-rtf)
Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue 16300 is really multiple issues. Each element is being submitted individually.
1. The content of the specification doc is the IXS specification and not RLUS. Nothing of the RLUS spec (beta1 and 2) is in the document except some titles.
Solution: make use of beta 2 specification doc (if a new document does not exist)
Resolution: Editorial resolution to produce PDF from the submitted Framemaker files.
Revised Text: PDF files were updated and posted from the Framemaker files by OMG staff.
Actions taken:
February 13, 2012: received issue
April 1, 2013: closed issue
Issue 17122: machine-consumable files are the same as in beta 2 version (ixs-rlus-rtf)
Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue 16300 is really multiple issues. Each element is being submitted individually.
2. The machine-consumable files are the same as in beta 2 version. In this version there are some serious inconsistences:
- The wsdl element "RLUSXMLSearch" does not exist in RLUSTypes.xsd. The correct element should be "RLUSSearchStruct" (or the RLUSTypes.xsd file uploaded is wrong). The issue affects get() list() and locate() operations.
Resolution: Replace RLUSXMLSearch with RLUSSearchStruct.
Revised Text: In the file RLUSTypes.xsd replace
<xs:element name="RLUSXMLSearch">
<xs:complexType>
<xs:complexContent>
<xs:extension base="RLUStypes:RLUSXMLSearch">
<xs:attribute name="semantic-signifiername" type="xs:string" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="RLUSXMLSearch">
With
<xs:element name="RLUSSearchStruct">
<xs:complexType>
<xs:complexContent>
<xs:extension base="RLUStypes:RLUSSearchStructType">
<xs:attribute name="semantic-signifiername" type="xs:string" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="RLUSSearchStructType">
Alternatively, use the RLUSTypes.XSD delivered in dtc/2012-09-05.
Actions taken:
February 13, 2012: received issue
April 1, 2013: closed issue
Issue 17123: more serious inconsistences in machine-consumable files (ixs-rlus-rtf)
Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue 16300 is really multiple issues. Each element is being submitted individually. #2 is parsed into three issues:
2. The machine-consumable files are the same as in beta 2 version. In this version there are some serious inconsistences:
- The RLUSTypes is declared as xmlns:RLUStypes="urn:RLUStypes.hssp.intel.com" and xmlns:xsd="http://www.omg.org/spec/RLUS/201012/RLUStypes" consequently some inconsistences arises in wsdls
Resolution: Delete the line xmlns:RLUSTypes="urn:RLUStypes.hssp.intel.com from RLUSTypes.xsd.
Revised Text: Delete the line below from the file RLUSTypes.xsd or use the RLUSTypes.xsd delivered in dtc/2012-09-05
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:RLUStypes="http://www.omg.org/spec/RLUS/201012/RLUStypes"
xmlns:RLUSexp="http://www.omg.org/spec/RLUS/201012/RLUSexpression"
xmlns="http://www.omg.org/spec/RLUS/201012/RLUStypes"
xmlns=”urn:RLUStypes.hssp.intel.com”
xmlns:datatypes="urn:hl7-org:v3"
Actions taken:
February 13, 2012: received issue
April 1, 2013: closed issue
Issue 17124: RLUSExpression.xsd is declared, in RLUSType.xsd, with the old intel namespace (ixs-rlus-rtf)
Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue 16300 is really multiple issues. Each element is being submitted individually. #2 is parsed into three issues:
2. The machine-consumable files are the same as in beta 2 version. In this version there are some serious inconsistences:
- RLUSExpression.xsd is declared, in RLUSType.xsd, with the old intel namespace
Resolution: Correct the namespace declaration
Revised Text: In the file RLUSTypes.xsd replace
xmlns:RLUSexp=" urn:RLUStypes.hssp.intel.com"
With
xmlns:RLUSexp="http://www.omg.org/spec/RLUS/201012/RLUSexpression"
Or, use the file RLUSTypes.xsd delivered as part of dtc/2012-09-05.
Actions taken:
February 13, 2012: received issue
April 1, 2013: closed issue
Issue 17125: Reintroduce generic wsdl (ixs-rlus-rtf)
Click here for this issue's archive.
Source: Sparx Systems Pty Ltd (Mr. James D. Baker, omg(at)objectsandaspects.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue 16300 is really multiple issues. Each element is being submitted individually.
3. The "generic" wsdl (present in beta1) is missed. The generic wsdl should be the normative file. The specialized wsdls (order and patient) should be only examples
Solution: Reintroduce generic wsdl
Resolution: The missing file was restored by OMG staff.
Revised Text: RLUSGenericService.wsdl is included in dtc/2012-09-05.
Actions taken:
February 13, 2012: received issue
April 1, 2013: closed issue