20080918 Informal Versioning Discussion

Informal notes from the versioning discussion, Q2, 20080918, between

• Jean-Henri Duteau, CA
• Keith Naylor, UK
• Charlie McCay, UK
• René Spronk, NL
• Bob Grant, CA

The participants share the fact they publish (annual) snapshot-style specifications which are made available to large groups of implementers. In such an environment there is a mixture of implementations that conform to a number of different versions of such snapshot-publications.

When upversioning, for technical, requirements or other reasons - vendors have to take a deep breath. We need a framework with a known threshold at which a contractual change kicks in; a framework were minor change can be absorbed, where backwards/forward compatibility is recognized without contractors jumping up and down. The framework extends to all artefacts including schema.

Next to versioning publications/artefacts at the national level, there may be additional publications (futher constraints) by an hierarchy of levels: provincial/state, vendor, developer (all with different publication cycles). Versioning framework needs to be applicable at all levels. Conformance statements deal with relationships between the layers.

Over-the-wire conformance

We need to figure out how to convey over the wire the conformance, I'm conformant to X. Implementers are starting to realize they'll have to implement multiple versions, so we need to identify versions in instances. -> ProfileId, with profile being an ID of the snapshot publication. Discussion of whether to send the ID of the-most-constrained profile (in a publication constraints hierarchy) or all of them.

Migration strategies

The projects share the fact that they have central applications which play a big role (.. and maybe also in resolving runtime versioning issues)

Local systems have different versions, have a contractual relationship with central hub, but not with eachother.

• Can't do a big-bang rollover to one new version overnight
• Sender has the ability to know version of receiver
• UK/NL: don't allow translations in central hub.
• CA: different scenario, doesn't apply. Always pre-negotiated versions between peer systems as part of contract. Central app is allowed to to transformation.
• use of XSLT by sender or receiver to transform between vendors - vendors don't want responsibility for doing the translation, neither does the publishing organization. Doesn't seem like a working solution.

A change that's compatible (e.g. a new optional attribute):

• claim conformance to OLD profile (and new one), and annotate (1) the new attribute in the instance. (1: special attribute "hl7 extension flag" to indicate "added as part of version 2"). Message is then profile1 and profile2. Base profile (most constrained) is profile1, first one in the profile list.
• Receiver can strip out all extensions of profileIds it doesn't understand. Extensions contain 1 profileId: the profileId at which they were initially introduced. Have it at the node level, one node for a object tree, not at each node.
• Requires a pre-processing transform.
• Requires use of ITS 1.1 (which is rather friendly for users of ITS 1.0)
• W3C Tag have a position paper on versioning of languages. This is in accordance with the principles of that document.

Alternative: use informal extensions instead of "hl7 extension flag". Only value is standard schema validation, nice for naive implementers. Doesn't work for sequences of non-mandatory-node followed by xs:any.

Need a new interaction if changes are not compatible. Those changes that force implementers "to touch their code again".

Action item

• Need to define Forwards/backwards compatibility