Draft Appendix: ITS R1.1 Extensibility Implementation Considerations

ITS R1.1 Extensibility Implementation Considerations

Background

ITS R1.1 introduces a new extensibility mechanism taken from SPL. This extensibility mechanism allows for cheaper implementation of forwards compatibility by allowing the use of the HL7extension attribute to mark an element as an extension. All processors must ignore elements labeled with the HL7extension attribute unless they know about the element. This way, an attribute from a later instance design can be gracefully introduced and a single processor can process both earlier extended versions and later versions.

There was considerable discussion about the relative merits of the two extensibility approaches (HL7extension and foreign namespace) and they way they interact with various implementation options.

We agree that we would add a few paragraphs as an appendix to the specification when it is balloted for DSTU. This is the draft appendix:

Draft Appendix : Implementation Considerations for Extensibility

This specification offers two mechanisms for extensibility:

• Placing extensibility content in foreign namespaces
• using the HL7extension attribute to label extensibility content.

The second method is specifically introduced to allow backwards and forward compatibility, and the content must be valid HL7 V3 content defined in the nominated model.

When processing an instance, all conformant implementations are expected to ignore content in a foreign namespace and any xml elements (other than the document root) marked with the HL7extension.

Depending on the parsing approach, this may not be straight forward. In particular, if some form of XML binding technology is used, extensibility content may be a problem. Some XML binding technologies can be configured to ignore foreign namespace content (note that the schemas that HL7 publish do not define the foreign namespace extensions using xs:any etc)

Instance processing applications must ignore both forms of extensibility content. If the parsing technology will be broken by these extensions, applications may need to run transforms that remove extensibility content first. This transform removes extensibility content:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
   xmlns="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3" xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <xsl:template match="/">
               <xsl:apply-templates/>
   </xsl:template>
   <xsl:template match="comment()">
       <xsl:copy/>
   </xsl:template>
   <xsl:template match="*">
       <xsl:if test="namespace-uri(.)='urn:hl7-org:v3' and not(@HL7extension)">
           <xsl:copy>
               <xsl:copy-of select="@*"/>
               <xsl:apply-templates/>
           </xsl:copy>
       </xsl:if>
   </xsl:template>
</xsl:stylesheet>

In some cases, trading partner agreements may exclude the use of these extensions, saving applications from this problem.

When using extensibility content, implementors should carefully weigh the price on the implementors, both those who wish to use the extended content and those who don't

Comments

put comments about the appendix here: