This wiki has undergone a migration to Confluence found Here
Difference between revisions of ""Shallow" vs. "Deep" LIMs (Templates)"
Jump to navigation
Jump to search
Line 5: | Line 5: | ||
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 asseret 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. |
− | ** This is asserted in the M&M Template Iplementation Specification | + | ** 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 sending system can 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 |
Revision as of 13:15, 29 October 2005
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.)
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 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 sending system can 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