This wiki has undergone a migration to Confluence found Here
Difference between revisions of "De-blue MessageCommunicationsControl"
Jump to navigation
Jump to search
(Marked as resolved) |
Rene spronk (talk | contribs) |
||
| Line 1: | Line 1: | ||
{{INM Workitem}} | {{INM Workitem}} | ||
| − | {{ | + | |
| − | + | ''See the [[Talk:{{PAGENAME}}|discussion page]] for discussions.'' | |
[[Image:RIM MessageCommunicationsControl.gif|250px|right|thumb|MessageCommunicationsControl subject area]] | [[Image:RIM MessageCommunicationsControl.gif|250px|right|thumb|MessageCommunicationsControl subject area]] | ||
| Line 7: | Line 7: | ||
The ''MessageCommunicationsControl'' subject area of the [[RIM]] (informally known as ''the blue classes'' or ''the bottom half of the RIM''), supports transmission oriented functions which allow [[Interaction]]s (e.g. Messages, Batches) to be exchanged. See [[HL7 Messaging Architecture]]. | The ''MessageCommunicationsControl'' subject area of the [[RIM]] (informally known as ''the blue classes'' or ''the bottom half of the RIM''), supports transmission oriented functions which allow [[Interaction]]s (e.g. Messages, Batches) to be exchanged. See [[HL7 Messaging Architecture]]. | ||
| − | == | + | ==Details== |
| − | === | + | ===Why haven't the MessageCommunicationsControl classes been modelled using the 4 base classes?=== |
As for the original reason to create these classes when the RIM was initially developed: | As for the original reason to create these classes when the RIM was initially developed: | ||
| Line 15: | Line 15: | ||
*At the [[Harmonization Meeting]] where this was decided, one person felt very strongly that the [[RIM Backbone]] was designed to apply to healthcare-specific portions of the RIM (it was designed with those portions in mind) and that the healthcare-specific portion was what HL7 had the most to offer to the world; several others tended to agree. There were several people who disagreed and felt the same modeling paradigm should apply throughout the entire model. Plus those portions in what is now called the [[MessageCommunicationsControl]] portion of the model were not modeled (at that time) in a similar fashion or with the same level of rigor and review. Plus there were no modeling personnel resources available at the time to enhance that portion of the model. | *At the [[Harmonization Meeting]] where this was decided, one person felt very strongly that the [[RIM Backbone]] was designed to apply to healthcare-specific portions of the RIM (it was designed with those portions in mind) and that the healthcare-specific portion was what HL7 had the most to offer to the world; several others tended to agree. There were several people who disagreed and felt the same modeling paradigm should apply throughout the entire model. Plus those portions in what is now called the [[MessageCommunicationsControl]] portion of the model were not modeled (at that time) in a similar fashion or with the same level of rigor and review. Plus there were no modeling personnel resources available at the time to enhance that portion of the model. | ||
| + | ===Why are the classes "blue" (as opposed to another color)=== | ||
As for the "blueness" of the classes: | As for the "blueness" of the classes: | ||
*It came from a permutation on [[Peter Coad]]'s "Java Modeling in Color with UML by Peter Coad" (ISBN:0-13-011510-X) in which blue is for 'catalogue' or 'reference' classes. See [http://en.wikipedia.org/wiki/UML_colors Wikipedia on UML colors] for a description. The other RIM colors are also derivatives of that coloring scheme. 'event' was red (hence Act and its derivative ActRelationship), Role was yellow, and Party (our Entity) was green. Coad didn't have the notion of Participation so we came up with tourquoise and reserved blue for the closest we had to 'catalogue or fixed resource.' | *It came from a permutation on [[Peter Coad]]'s "Java Modeling in Color with UML by Peter Coad" (ISBN:0-13-011510-X) in which blue is for 'catalogue' or 'reference' classes. See [http://en.wikipedia.org/wiki/UML_colors Wikipedia on UML colors] for a description. The other RIM colors are also derivatives of that coloring scheme. 'event' was red (hence Act and its derivative ActRelationship), Role was yellow, and Party (our Entity) was green. Coad didn't have the notion of Participation so we came up with tourquoise and reserved blue for the closest we had to 'catalogue or fixed resource.' | ||
| Line 21: | Line 22: | ||
[[Image:Wrappers_blue.jpg|300px|right|thumb|Transmission wrappers]] | [[Image:Wrappers_blue.jpg|300px|right|thumb|Transmission wrappers]] | ||
| − | Given various discussions within [[INM]] as well as with the [[SOA SIG]] some radical changes have to be made to the [[Transmission Wrapper]]s | + | Given various discussions within [[INM]] as well as with the [[SOA SIG]] some radical changes have to be made to the [[Transmission Wrapper]]s. Increasingly the blue classes exhibit the same characteristics as the base RIM classes. Given the fact that things like Document and Application etc. already are RIM classes the question has been raised whether or not the blue classes should be remoddeled as base RIM classes. This adds some abstraction ([[Structural Attributes]]) which will show at the XML level. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
There is a secundary motivation for doing this: it will allow for requirements analysis to be (re)done. The existing blue classes were mostly ported from v2 and are based on requirements that may not exist for v3. The fact that INM has already removed attributes from the blue classes because of a "lack of underlying use-case" is a symptom of the need to do a requirements analysis. | There is a secundary motivation for doing this: it will allow for requirements analysis to be (re)done. The existing blue classes were mostly ported from v2 and are based on requirements that may not exist for v3. The fact that INM has already removed attributes from the blue classes because of a "lack of underlying use-case" is a symptom of the need to do a requirements analysis. | ||
| − | + | MnM sees no functional objection to the wrappers being remodelled in terms of the base classes. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 15:37, 21 October 2006
This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.
See the discussion page for discussions.
The MessageCommunicationsControl subject area of the RIM (informally known as the blue classes or the bottom half of the RIM), supports transmission oriented functions which allow Interactions (e.g. Messages, Batches) to be exchanged. See HL7 Messaging Architecture.
Contents
Details
Why haven't the MessageCommunicationsControl classes been modelled using the 4 base classes?
As for the original reason to create these classes when the RIM was initially developed:
- It was not felt to be part of the 'shared, cross-domain semantics that the RIM was designed to represent.' Rather, it represented a 'resource' of messaging-appropriate semantics (remember, the RIM stared out as an internal document that was only imagined to be referenced by specification developments and never used as an information-model per se. But even in this view, the 'blue' classes were deemed to be on a different plane than the other classes and, at least in some sense, did seem vaguely conceptually similar to Coad's blue classes.). Various ITSs would utilize various aspects of the blue classes in implementation-specific ways in contrast to much of the RIM semantics per se, which would, for the most part, be utilized as modeled.
- At the Harmonization Meeting where this was decided, one person felt very strongly that the RIM Backbone was designed to apply to healthcare-specific portions of the RIM (it was designed with those portions in mind) and that the healthcare-specific portion was what HL7 had the most to offer to the world; several others tended to agree. There were several people who disagreed and felt the same modeling paradigm should apply throughout the entire model. Plus those portions in what is now called the MessageCommunicationsControl portion of the model were not modeled (at that time) in a similar fashion or with the same level of rigor and review. Plus there were no modeling personnel resources available at the time to enhance that portion of the model.
Why are the classes "blue" (as opposed to another color)
As for the "blueness" of the classes:
- It came from a permutation on Peter Coad's "Java Modeling in Color with UML by Peter Coad" (ISBN:0-13-011510-X) in which blue is for 'catalogue' or 'reference' classes. See Wikipedia on UML colors for a description. The other RIM colors are also derivatives of that coloring scheme. 'event' was red (hence Act and its derivative ActRelationship), Role was yellow, and Party (our Entity) was green. Coad didn't have the notion of Participation so we came up with tourquoise and reserved blue for the closest we had to 'catalogue or fixed resource.'
Future Options
Given various discussions within INM as well as with the SOA SIG some radical changes have to be made to the Transmission Wrappers. Increasingly the blue classes exhibit the same characteristics as the base RIM classes. Given the fact that things like Document and Application etc. already are RIM classes the question has been raised whether or not the blue classes should be remoddeled as base RIM classes. This adds some abstraction (Structural Attributes) which will show at the XML level.
There is a secundary motivation for doing this: it will allow for requirements analysis to be (re)done. The existing blue classes were mostly ported from v2 and are based on requirements that may not exist for v3. The fact that INM has already removed attributes from the blue classes because of a "lack of underlying use-case" is a symptom of the need to do a requirements analysis.
MnM sees no functional objection to the wrappers being remodelled in terms of the base classes.
