Difference between revisions of "MnM Minutes WGM 20080115"
| Line 1: | Line 1: | ||
==Monday Q1== | ==Monday Q1== | ||
===Hot topic: update mode=== | ===Hot topic: update mode=== | ||
| − | ''Hot topics/update mode'' | + | ''Agenda: Hot topics/update mode'' |
Grahame Grieve (GG) presented concerns related to "Update Mode" when preparing Abstract Data Types Release 2: | Grahame Grieve (GG) presented concerns related to "Update Mode" when preparing Abstract Data Types Release 2: | ||
#Clarity on terms and definitions | #Clarity on terms and definitions | ||
| Line 43: | Line 43: | ||
Line 146 '''''(Grieve/Beeler 11-0-0)''''' It is not specified whether or what kind of change has occurred to the item. | Line 146 '''''(Grieve/Beeler 11-0-0)''''' It is not specified whether or what kind of change has occurred to the item. | ||
| + | |||
| + | ==Monday Q2== | ||
| + | ''Agenda: Hot topics - Interaction & Versioning, V3 Substantivity'' | ||
| + | |||
| + | '''Discussion:''' | ||
| + | |||
| + | What are rules for semantic backwards compatibility? They conflict with ISO definition. | ||
| + | |||
| + | How is versioning, backwards compatibility related to interaction version (in its name), profileid, etc.? | ||
| + | |||
| + | Could evaluate whether new artifacts (compliant with the new/modified model) can be parsed by the current schema. | ||
| + | |||
| + | Some say: “I conform to the implementation guide of 2006” e.g. | ||
| + | |||
| + | In Canada, everywhere a schema is constrained, a new artifact is created. So, perhaps the question is to use a realm. | ||
| + | |||
| + | Rene: We should encourage use of universal artifacts. Pure constraint on a UV then used in a realm model. (e.g. remove some classes, and change schema to reflect) | ||
| + | |||
| + | After much discussion voted on a motion to accept the following assertion: | ||
| + | |||
| + | '''Assertion:''' | ||
| + | |||
| + | Supporting an artifact id (interactionId, typeId) means that: | ||
| + | *the application uses the semantic model associated with that id (plus possible ‘ignorable’ extensions) | ||
| + | *the application uses the syntax associated with an ITS implementations of the artifact | ||
| + | *it does not NOT mean full support for the content expressed by the artifact | ||
| + | *definition of exactly what content is supported is determined by the profileId | ||
| + | *applications MAY raise errors when instances do not declare a recognized profile or do not comply with one of the declared profiles. | ||
| + | *Interoperability requires knowledge of both artifactId and profileId. | ||
| + | *In the absence of a profileId, the expectation is that the receiver will fully support any instance allowed by the artifact, though it may ignore elements with conformance of optional (blank) and must ignore non-supported extensions. | ||
| + | |||
| + | In order to reconcile historical use in CDA, should recommend that profileId be added to CDA for R3. | ||
| + | |||
| + | Motion: '''''(McCay/Spronk 9-0-2)''''' MnM recommends to Implementation & Conformance that the above assertion be adopted and reflected in the Refinement and Localization document. | ||
| + | |||
| + | '''Continuing discussion''' | ||
| + | #Under what circumstances should realms create “realm” artifacts (as opposed to UV) | ||
| + | #*some constraints cause schema element name changes in XML ITS | ||
| + | #*other constraints are just restrictions with no element name changes | ||
| + | #:If instances created against the realm constraint would not validate against the UV specification (for any ITS), it must be treated as a realm artifact (a new artifact id must be issued for that realm code). | ||
| + | #:''NOTE:'' “extension” elements using foreign namespaces or other flags do not impact the above analysis because conformant applications are required to ignore them during validation. | ||
| + | |||
| + | In other circumstances, you MAY create a new artifact or MAY reference the UV artifact as well as a profileId with realm constraints. | ||
| + | |||
| + | Pro’s of the new artifact: | ||
| + | *places all constraints in a single specification, simplifies testing | ||
| + | |||
| + | Pro’s of the UV version: | ||
| + | *enables determination of interoperability possibility between cross-realm applications. | ||
| + | *simplifies determination of forward and backward compatibility by separating constraints from syntax | ||
| + | |||
| + | The following will be discussed Friday Q2: | ||
| + | # When realms reference UV models “with constraints”, need to reference versions of constraints separate from UV interaction version. | ||
| + | #CDA has a different definition for backward compatibility than our “semantic backwards compatibility” definition. | ||
| + | #ISO term for what we call “backward compatibility” is “forward compatibility” | ||
| + | #Sometimes users adopt artifacts prior to “freezing” at ballot, which is when version ids are assigned. How do they tell what ‘non-official’ version they’re referencing? | ||
==Tuesday Q1== | ==Tuesday Q1== | ||
Revision as of 17:56, 18 January 2008
Contents
Monday Q1
Hot topic: update mode
Agenda: Hot topics/update mode Grahame Grieve (GG) presented concerns related to "Update Mode" when preparing Abstract Data Types Release 2:
- Clarity on terms and definitions
- Clarity where update mode is documented and how much information data types needs to contain?
- The update mode descriptions in the HDF do not seem to agree with Abstract Data Types R2 Table 59.
The group discussed possible documentation options, and suggests the following:
Prepare a new document in the ballot package in V3 Foundation, before Reference Information Model. Initial title is "Core Properties of V3 Models". An initial outline (below) was discussed but has been superseded by th evolving document found at Core_Properties_of_V3_Models
- Introduction to how RIM & data types fit together
- principles
- classes
- properties
- cardinality
- mandatory / conformance
- attributes
- vocabulary concepts & coding strength
- associations
- concepts
- nullFlavor
- typing (typeId & flavorId & templates)
- conformance & testing
- update principles
- referencing principles
- updateMode
- use cases
- data types
Motion: Grieve/McKenzie (9-0-2) That MnM ballots this document described above for normative track; Woody Beeler and Grahame Grieve will be co-authors for this coming ballot cycle. “update mode” will be renamed at the abstract level to “usage mode”.
Ballot reconciliation on Abstract Data Types
MnM took on various data type abstract ballot negatives, referred from InM. Following reference line items from Ballot reconciliation spreadsheet.
Line 141 (Grieve/Coller 11-0-0)
Line 142 (Grieve/Coller 11-0-0) If the item was (or is to be ) added, having not been present immediately before. (If it is already present, this may be treated as an error condition)
Line 143 (Grieve/Beeler 11-0-0) If the item existed previously and has (or is to be) revised. (If an item does not already exist, this may be treated as an error condition)
Line 146 (Grieve/Beeler 11-0-0) It is not specified whether or what kind of change has occurred to the item.
Monday Q2
Agenda: Hot topics - Interaction & Versioning, V3 Substantivity
Discussion:
What are rules for semantic backwards compatibility? They conflict with ISO definition.
How is versioning, backwards compatibility related to interaction version (in its name), profileid, etc.?
Could evaluate whether new artifacts (compliant with the new/modified model) can be parsed by the current schema.
Some say: “I conform to the implementation guide of 2006” e.g.
In Canada, everywhere a schema is constrained, a new artifact is created. So, perhaps the question is to use a realm.
Rene: We should encourage use of universal artifacts. Pure constraint on a UV then used in a realm model. (e.g. remove some classes, and change schema to reflect)
After much discussion voted on a motion to accept the following assertion:
Assertion:
Supporting an artifact id (interactionId, typeId) means that:
- the application uses the semantic model associated with that id (plus possible ‘ignorable’ extensions)
- the application uses the syntax associated with an ITS implementations of the artifact
- it does not NOT mean full support for the content expressed by the artifact
- definition of exactly what content is supported is determined by the profileId
- applications MAY raise errors when instances do not declare a recognized profile or do not comply with one of the declared profiles.
- Interoperability requires knowledge of both artifactId and profileId.
- In the absence of a profileId, the expectation is that the receiver will fully support any instance allowed by the artifact, though it may ignore elements with conformance of optional (blank) and must ignore non-supported extensions.
In order to reconcile historical use in CDA, should recommend that profileId be added to CDA for R3.
Motion: (McCay/Spronk 9-0-2) MnM recommends to Implementation & Conformance that the above assertion be adopted and reflected in the Refinement and Localization document.
Continuing discussion
- Under what circumstances should realms create “realm” artifacts (as opposed to UV)
- some constraints cause schema element name changes in XML ITS
- other constraints are just restrictions with no element name changes
- If instances created against the realm constraint would not validate against the UV specification (for any ITS), it must be treated as a realm artifact (a new artifact id must be issued for that realm code).
- NOTE: “extension” elements using foreign namespaces or other flags do not impact the above analysis because conformant applications are required to ignore them during validation.
In other circumstances, you MAY create a new artifact or MAY reference the UV artifact as well as a profileId with realm constraints.
Pro’s of the new artifact:
- places all constraints in a single specification, simplifies testing
Pro’s of the UV version:
- enables determination of interoperability possibility between cross-realm applications.
- simplifies determination of forward and backward compatibility by separating constraints from syntax
The following will be discussed Friday Q2:
- When realms reference UV models “with constraints”, need to reference versions of constraints separate from UV interaction version.
- CDA has a different definition for backward compatibility than our “semantic backwards compatibility” definition.
- ISO term for what we call “backward compatibility” is “forward compatibility”
- Sometimes users adopt artifacts prior to “freezing” at ballot, which is when version ids are assigned. How do they tell what ‘non-official’ version they’re referencing?
Tuesday Q1
HDF Ballot Reconciliation
Attendees
- Bernard Jackson (BERNARD@exchange.clemson.edu)
- Susan W. McClacherty (susan.mcclacherty@khpa.ks.gov)
- Scott Robertson (sScott.M.Robertson@kp.org)
- Ioana Singureanu (ioana@eversolve.com)
- Freida Hall (Freida.Hall@va.gov)
The committee reviewed the comments submitted by Kaiser Permanente. Scott Robertson indicated that Kaiser will withdraw the negative assuming that the proposed resolutions are applied in full.
--Ioana13 16:56, 15 January 2008 (CST)
Tuesday Q2
HDF Ballot Reconciliation
Attendees
- Lee Coller (lee.coller@oracle.com)
- Susan W. McClacherty (susan.mcclacherty@khpa.ks.gov)
- Scott Robertson (Scott.M.Robertson@kp.org)
- Sina Mowzoon (Sina.Mowzoon@azahccs.gov)
- Ioana Singureanu (ioana@eversolve.com)
- Freida Hall (Freida.Hall@va.gov)
- Kathleen Connor (Kathleen.Connor@foxsys.com)
The committee reviewed the comments submitted by Virginia Lorenzi, Jane Curry, and VA. The changes resulting from the comments provided by VA will be substantive.
--Ioana13 16:56, 15 January 2008 (CST)
