130 likes | 147 Views
This proposal suggests an extension mechanism for HL7v3 messages or document definitions that allows for non-breaking changes. It aims to support versioning and the introduction of additions without breaking existing implementations.
E N D
HL7 XML ITS R1.1 Charlie McCay charlie@ramseysystems.co.uk
Contents • Scope • Proposal • Precedents • Open Issues
Scope • Extension mechanism that allows for the introduction of additions to HL7v3 message or document definitions as non-breaking changes • This mechanism will support non-breaking changes to both the underlying normative specification and to any profile or template that has been applied
Proposal It is not clear at this stage which of the following to do: • Simple • Add SPL informal extension text to XML ITS • Allow local implementations to determine how this is used to support versioning • Detailed • Provide explicit support for versioning of binding to HL7 and locally defined structures (ie versioning of normative structures and local templates/profiles)
Status Quo – HL7 version handling • This page will describe current versioning rules as determined by localisation document, HDF, and/or MnM lore
Status Quo – XML ITS R1 • The specification states that “local extensions” MUST be in a foreign namespace • The specification states that different versions of the same artefact are expected to be an XSLT transform apart • The Specification is silent on how unexpected content in the hl7 namespace should be treated (though the committee expectation was that it would be treated as an error) • The distinction between breaking and non-breaking changes is not made (all changes are assumed to be breaking)
Precedents • SPL Structured Product Labelling • XML 1.1 • XSLT 2.0
SPL • SPL is a CDA like document for Pharmaceutical Product Labelling, and is strongly supported by the FDA (and others) • It supports the foreign namespace extensibility, but states that RIM-compliant extensions should be in the HL7 namespaces, with an XML attribute “HL7extension” (with non-empty content) to indicate that it is not defined in the underlying SPL specification.
XML 1.1 • The set of well formed XML instances was extended to support later versions of Unicode, and to support additional newline characters. • All XML 1.0 documents are accepted by XML 1.1 processors • Switch from “what is not defined is forbidden”, to “what is not defined is permitted” unless explicitly forbidden
XSLT 2.0 • Has a an extension and fallback mechanism for selectively supporting V2 features within a V1 stylesheet, and for providing fallback support when features (of the XSLT or extensions) are not supported
Open Issues • Should the simple SPL definitions extension syntax be used, or better defined mechanism such as that in XSLT? • Should the same mechanism be used for supporting versioning (and fallback) for profiles/templates and for interactions / document definitions • Others to be established…
References • SPL R2 - http://www.hl7.org/Memonly/downloads/Standards_SPL/SPL_Specification_R2.zip • XML 1.1 - http://www.w3.org/TR/xml11/ • XSLT 2.0 - http://www.w3.org/TR/xslt20/#extension • XML ITS R1 - http://www.hl7.org/v3ballot/html/infrastructure/itsxml/messaging-its-xml.htm
Background • 2003 article with W3C perspective: http://www.xml.com/pub/a/2003/12/03/versioning.html • Jan 2006 W3C schema versioning usecases - http://www.w3.org/XML/2005/xsd-versioning-use-cases/