This wiki has undergone a migration to Confluence found Here

Difference between revisions of ""Shallow" vs. "Deep" LIMs (Templates)"

From HL7Wiki
Jump to navigation Jump to search
Line 2: Line 2:
 
== Background ==
 
== Background ==
  
In discssion 10/29/2005, M&M discussed the issue of defining and supporting both "shallow" and "deep" LIMs. (This occurred after a discussion that templates are represented as a "Local Information Model" - LIM.)
+
In discussion at the out-of-cycle constraints meeting in Washington on 10/29/2005, M&M discussed the issue of defining and supporting both "shallow" and "deep" LIMs. (This occurred after a discussion that templates are represented as a "Local Information Model" - LIM.)
  
The discussion arose in the context of determining how to asseret the binding to a LIM in a message instance.  The issue arises because
+
The discussion arose in the context of determining how to assert the binding to a LIM in a message instance.  The issue arises because
  
 
* The element names in a LIM do <b><u>not</u></b> need to be the same as the name in the CIM (Message Type) that the LIM element constrains.  
 
* The element names in a LIM do <b><u>not</u></b> need to be the same as the name in the CIM (Message Type) that the LIM element constrains.  
Line 16: Line 16:
 
* Absent such identification in the instance, there are numerous example cases in which the coordinated tree walk becomes computationally burdensome and some in which it is virtually impossible.
 
* Absent such identification in the instance, there are numerous example cases in which the coordinated tree walk becomes computationally burdensome and some in which it is virtually impossible.
  
As a consequence, discussion arose on the mechanisms by which such references can be made.  It included concerns that the current method of inclusion of CMETs in a design may obscure the identification of where a CMET begins owing to the fact that, in the XML ITS, the element naming is the same whether a CMET is used or the same content is fully expressed in the parent design.
+
As a consequence, discussion arose on the mechanisms by which such references can be made.  It included concerns that the current method of inclusion of CMETs in a design may obscure the identification of where a CMET begins owing to the fact that, in the XML ITS, the element naming is the same whether a CMET is used or the same content is fully expressed in the parent design, and that this obscures the way in which a LIM may refer to other LIM's to allow users to build LIMs that reuse the concepts defined in other LIM's in a greater pattern.
  
 
This led to the consideration of "shallow" versus "deep" LIMs (templates).
 
This led to the consideration of "shallow" versus "deep" LIMs (templates).

Revision as of 14:07, 29 October 2005

Background

In discussion at the out-of-cycle constraints meeting in Washington on 10/29/2005, M&M discussed the issue of defining and supporting both "shallow" and "deep" LIMs. (This occurred after a discussion that templates are represented as a "Local Information Model" - LIM.)

The discussion arose in the context of determining how to assert the binding to a LIM in a message instance. The issue arises because

  • The element names in a LIM do not need to be the same as the name in the CIM (Message Type) that the LIM element constrains.
    • This is asserted in the M&M Template Iplementation Specification.
    • This rule allows a single template (LIM) to be asserted as a constraint against multiple, independently defined message types (CIMs)
  • If a receiving system seeks to validate a received instance against the templates, the receiving system must perform a coordinated "tree walk" on both the message and the LIM simultaneously in order to determine which LIM element should be governing each node.
  • If the sending system can (and does) include in the nodes of the instance message an identification of the LIM element used to constrain the instance node, the coordinated tree walk is straightforward.
  • Absent such identification in the instance, there are numerous example cases in which the coordinated tree walk becomes computationally burdensome and some in which it is virtually impossible.

As a consequence, discussion arose on the mechanisms by which such references can be made. It included concerns that the current method of inclusion of CMETs in a design may obscure the identification of where a CMET begins owing to the fact that, in the XML ITS, the element naming is the same whether a CMET is used or the same content is fully expressed in the parent design, and that this obscures the way in which a LIM may refer to other LIM's to allow users to build LIMs that reuse the concepts defined in other LIM's in a greater pattern.

This led to the consideration of "shallow" versus "deep" LIMs (templates).

"Deep" LIMs (templates)

A "deep" lim:

    1. is simply any valid static model, with the full richness and complexity allowed in any HL7 message type design.
    2. establishes constraints for all the elements that it contains.

Although another LIM might also be asserted against elements that are "internal" to the LIM in question