This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Design principles: Clone names"

From HL7Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Lore}}
 
{{Lore}}
{{MnM Open Hot Topic}}
+
''See the [[Talk:{{PAGENAME}}|discussion page]] for discussion related to this page.''
  
 +
*Semantics of class clones derived from the RIM backbone (upper portion of the RIM) should '''never''' be inferred from the clone name.  They should only be inferred from the structural attributes of the clone and its situation in the model.
 +
*Semantics of clone names derived from the lower part of the RIM (blue classes) at present must be inferred from clone names as there are no structural attributes which may be used to communicate those semantics.
  
= Issue =
+
= Details =
The v3 design principle states that when it comes to the interpretation of RIM-derived models one should be able to derive the full '''computable''' semantics of the model without having to look at the names of cloned classes. The purpose of the clone names is to both ensure unique type names for code generation and instance validation, as well as to make those semantics clear to the average human reader.
+
The v3 design principle states that when it comes to the interpretation of RIM-derived models one should be able to derive the full '''computable''' semantics of the model without having to look at the names of cloned classes.  
  
Grahame: is this a v3 design principle? Or an ITS principle? I suspect that it's a bit of both [2 Aug 2006]
+
The fundamentals of this design principle are that the semantics of v3 instances should be fully expressed using the 'semantic' attributes (classCode, moodCode, typeCode, etc.) and constraints on them.  (E.g. fixed values, constrained domains, etc.)  The meaning of an instance is found by looking at the RIM definitions and vocabulary definitions.  Clone names are used to help expose the semantics expressed by these attributes to the casual reader.  It is the responsibility of modelers to ensure that the clone names selected correspond to the constraints chosen.
  
Two open issues:
+
The challenge to this position is found in the "bottom" half of the RIM where there are few, if any, semantic attributes exist.  For those classes, the source of semantics is limited to RIM definitions as there is no structural vocabulary.  For some classes, specifically query parameters, different clones have different semantics, but there is no mechanism to distinguish the different meaning of each clone. At present the semantics must be inferred from the clone names.
*The above lore needs to be formally voted upon to document it, or if already ahs been voted upon we need a link to a document that contains the description.
 
*The description needs to be clarified to state that this extents to all RIM classes, and not (as some say) just those classes that are part of the normative or "upper" part of the RIM.
 
 
 
= Discussion =
 
The fundamentals of this principle are that the semantics of v3 instances should be fully expressed using the 'semantic' attributes (classCode, moodCode, typeCode, etc.) and constraints on them.  (E.g. fixed values, constrained domains, etc.)  The meaning of an instance is found by looking at the RIM definitions and vocabulary definitions.  Clone names are used to help expose the semantics expressed by these attributes to the casual reader.  It is the responsibility of modelers to ensure that the clone names selected correspond to the constraints chosen.
 
 
 
The challenge to this position is found in the "bottom" half of the RIM where there are few, if any, semantic attributes exist.  For those classes, the source of semantics is limited to RIM definitions as there is no structural vocabulary.  For some classes, specifically query parameters, different clones have different semantics, but there is no mechanism to distinguish the different meaning of each clone.
 
 
 
The question basically comes down to this:
 
 
 
Should a semantic attribute be added to those classes in the "bottom half" of the RIM to fully express the semantics? Or is it legitimate to use the existing clone name for this purpose?
 
 
 
:Rephrased in a generic fashion to focus on design principle without getting sidetracked into the"specifics of the ''semanticsText'' issue. [[User:Rene spronk|Rene spronk]] 18:58, 2 Aug 2006 (CDT)
 

Latest revision as of 09:02, 21 October 2006

See the discussion page for discussion related to this page.

  • Semantics of class clones derived from the RIM backbone (upper portion of the RIM) should never be inferred from the clone name. They should only be inferred from the structural attributes of the clone and its situation in the model.
  • Semantics of clone names derived from the lower part of the RIM (blue classes) at present must be inferred from clone names as there are no structural attributes which may be used to communicate those semantics.

Details

The v3 design principle states that when it comes to the interpretation of RIM-derived models one should be able to derive the full computable semantics of the model without having to look at the names of cloned classes.

The fundamentals of this design principle are that the semantics of v3 instances should be fully expressed using the 'semantic' attributes (classCode, moodCode, typeCode, etc.) and constraints on them. (E.g. fixed values, constrained domains, etc.) The meaning of an instance is found by looking at the RIM definitions and vocabulary definitions. Clone names are used to help expose the semantics expressed by these attributes to the casual reader. It is the responsibility of modelers to ensure that the clone names selected correspond to the constraints chosen.

The challenge to this position is found in the "bottom" half of the RIM where there are few, if any, semantic attributes exist. For those classes, the source of semantics is limited to RIM definitions as there is no structural vocabulary. For some classes, specifically query parameters, different clones have different semantics, but there is no mechanism to distinguish the different meaning of each clone. At present the semantics must be inferred from the clone names.