2012-10-09 V3 Datatypes Task Force

From HL7 TSC
Jump to navigation Jump to search

Scope and mandate of this group: Need a recommendation for the V3 Modeling to the TSC.

Occurs every Tuesday effective 9/25/2012 until 11/27/2012 from 1:00 PM to 2:00 PM.

TSC concall coordinates Dial 770-657-9270 and enter pass code 985371#

Co-chairs: Woody, Charlie
Today's Chair: Woody

Attendees:

  • Charlie Mead - present
  • Hugh Glover - will be late
  • Paul Knapp - present
  • Austin Kreisler - regrets
  • Lloyd McKenzie -
  • Ron Parker - present
  • John Quinn - present
  • Pat van Dyke - present
  • Mead Walker - present
Scribe: Lynn Laakso

past meeting notes:


Action Items:

Action Items:

  • Charlie to write his narrative of Oracle's versioning strategy for reference.
  • Woody asks Hugh to write up the choices as he sees them. See "Motion" below.

Product Line principles:

  • CDA Principles - R1-R2 ; R2-R3 (Austin)
  • FHIR Principles - evolving but more rigid than V3 (Lloyd) - see attachment
  • V2 Compatibility - obtain from Chapter 2 (Mead) - see attachment
  • V3 Principles - located in package note to readers on ballot site in section 5.2

Agenda

Draft Motion (Hugh):

  • HL7 has not and will not guarantee wire format backward compatibility of V3 payloads as the standard evolves. However HL7 recognises that in some circumstances breaking wire format backward compatibility will cause significant difficulty to users and that this in turn will reflect badly on HL7 and have a substantial negative impact on the adoption of V3. In such circumstances, and where a resolution can be found, HL7 will publish multiple versions of affected schemas so that both new versions and old wire format backward compatible versions are available to the user community that has been affected.
  • Discussion points:
    • The reason for trying to provide a backward compatible version is HL7 self-interest – we lose credibility if we don’t. We are not committing to satisfy all backward compatibility requirements everywhere.
    • We are only committing to provide a solution where one can be found.
    • We are not committing to providing the solution to everyone – but only to the group that has the issue.

Minutes

Convene at 1:10 PM

  • Roll call
  • Acknowledged minutes of 2012-10-02_V3_Datatypes_Task_Force
  • Charlie's narrative of versioning strategy reviewed. The provider is a software provider.
    • Perspectives for both customer/consumer and provider are important to note.
    • Ron says we need strategy as requested to create an official policy, but not just frame this but do something specific in the Datatypes scenario, what sunsetting might mean for this specific problem.
    • Woody notes we have all three areas considered except perhaps for CDA but may not have described them fully (versioning, component migration, and sunsetting/component retirement from official support). Looking at V3 messaging terms, articulate the approach for support during migration.
    • What are the responsibilities for solving the problems during migration, asks Ron. Limit duration of parallel support. Can we tag in to other updates to FDA's client code to say "as long as you're updating, make this migration as well".
    • Woody notes we must define the scope of the overlap.
    • John recalls in the LRI errata issue as a cochair making the statement that the errata will be in the next published version, but that implicitly guarantees they will be in the next version as written and such a guarantee may be impossible with the reconciliation and consensus process in balloting.
    • Woody notes we have several paths for change: MnM has technical corrections, "Updates", and errata. Paul adds that typically errata are breaking changes, otherwise you wouldn't bother.

Mead joins


  • Review Product Line principles:
    • V2 Compatibility - obtain from Chapter 2 (Mead) - see attachment
      • Review deprecating messages 2.1.3 section. It doesn't really address a sunsetting policy. The deprecated component is not removed from the standard. It doesn't break wire format since it's still defined in the same location but you're supposed to ignore it.
      • Charlie notes that with Oracle it had to do with test beds and what they will support. Cross-product line testing is at issue.
      • Paul notes if a standard lives for 5 years we should be prepared to support it for 5 years.
    • V3 Principles - located in package note to readers on ballot site in section 5.2
      • If we have a MDA and serializations faithfully rendered in the models, then as the models change the wire changes notes Paul. We could choose to drop the rule of faithful rendering... Mead suggests a faithful rendering with an isomorphic model.
      • Obsolescent message structure section reviewed. Woody adds they've never declared a message obsolescent but have deprecated attributes in the RIM.
      • If you made one obsolescent and offer an alternative you have to offer a transform. Charlie notes that those are data migration strategies, and while Oracle gave clients tools to migrate their data - they felt it was their responsibility to identify how the transformation should be done. They ensured the mechanics but not the labor.
      • Essentially we declared DT R1 obsolescent after R2 ballot and made efforts toward publication of R2 in the normative edition. Alternate message structures provided, e.g. in NE2012. We did not undertake transformations, but it may be possible to do so. Collection as an object itself is not semantically represented in the prior version so that would not be transformable backwards. Woody suggests we re-frame the problem in the terms used by the V3 deprecation guidance.
      • Woody further categorizes RIM changes, Data Types changes, and "inadvertent changes" from the design process. Some who implemented from the ballot find there are:
        • serialization pattern changes,
        • renaming when new elements added, or
        • changes in the "schema-generation tools".
      • Paul asks how you distinguish between the "time/edition" of a "message" to identify externally when a message structure was published. Woody notes that a 'community' should implement from a SINGLE Normative Edition and that needs to be better communicated. Normative editions have elements that are named the same but may be different. That may be perceived from customer perception as lack of operational consistency notes Paul. Woody notes that it may change again with the use of the Canadian Generator.
      • Common product model, referenced from SPL, is broader than SPL use. If you can't change CPM because of the install base of SPL that is a problem. Even if it uses a local version of CPM elements, but what happens when I get into safety reports? How big is the pond if SPL keeps itself separate? How much to we keep in the "special" environment going forward...
      • Woody would like to undertake revision of V3 principles coupled with recent actions and statements, to articulate better how V3 has been managed since 2004. Ron agrees it's helpful to frame the context but cautions against the Task Force taking on the solution. If we, for some period of time, have a dual datatypes strategy, we can publish content for a selected set of work BUT: when do we sunset that strategy, and what is the scope (body of work) of that exception? Paul asks if that fork evolves with RIM changes, etc or is it completely frozen?
      • Woody asks Mead if there is consensus on what the scope of this should be? There are elements in CDA that would like to see stability but generally it is the FDA on behalf of all SPL implementers (including Pharmacy). When schemas change in CDA R3 this will come up again. It's currently on a breaking change path.
    • FHIR Principles - evolving but more rigid than V3 (Lloyd) - see attachment
      • Extensions, or sticking things at the end will look less modeled down the road.
    • CDA Principles - R1-R2 ; R2-R3 (Austin)


Woody asks about next meeting's agenda. Charlie notes we needed to show a general framework of the problem and use the framework to address the Datatypes problem. Documenting what we have in place is important and then apply the Oracle model. CDA R2 and R3 fall outside our scope but will certainly be affected by this. Woody recalls we have an obligation to have a response or recommendation at the end of this month. Paul notes having a framework into which a petitioner can write a request and it can be vetted against the mechanisms we're addressing. The Petitioner may not like the answer but that's a separate discussion.

Next meeting 2012-10-16 V3 Datatypes Task Force

Adjourned 2:11 PM EDT

Retrieved from "https://tscwiki.hl7.org/w/index.php?title=2012-10-09_V3_Datatypes_Task_Force&oldid=10350"