This wiki has undergone a migration to Confluence found Here

Difference between revisions of "RIM based ITS"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
[[category:RIMBAA Issue]]  
 
[[category:RIMBAA Issue]]  
 
The '''RIM based ITS''' (or '''RS XML ITS''', a term used by the [[RIMBAA]] WG) is an [[ITS]] that is based on 'pure RIM semantics', i.e. an ITS that defines an XML syntax which allows for the XML to be processed solely based on its contents (and not on Class Clone names, or knowledge of templates/interactions used).
 
The '''RIM based ITS''' (or '''RS XML ITS''', a term used by the [[RIMBAA]] WG) is an [[ITS]] that is based on 'pure RIM semantics', i.e. an ITS that defines an XML syntax which allows for the XML to be processed solely based on its contents (and not on Class Clone names, or knowledge of templates/interactions used).
 +
 +
We currently have the XML ITS R1. It has the following properties:
 +
*element names identify Rim clone classes
 +
*properties that are defaulted in the Rim specific model (CIM) are not represented in the instance
 +
*the order of associations in the instance is fixed for predictability - based on element names
 +
*whether something is play or scoper etc is implicit (in the rim specific model) rather than in the instance
 +
*You need the MIF to convert from the instance to a general RIM graph.
 +
 +
The RIM serialization would have different properties:
 +
*element names identify the RIM back bone associations
 +
*properties that are defaulted in the general rim are not represented in the instance
 +
**Almost all structured attributes (e.g. classCode, moodCode) will be present in all instances
 +
*the order of the associations is irrelevant: only their semantics matter
 +
*player/scoper etc is explicit in the instance
  
 
==Analysis==
 
==Analysis==
 
Characteristics of instances that conform to this ITS
 
Characteristics of instances that conform to this ITS
*All structured attributes (e.g. classCode, moodCode) have to be present in all instances
 
 
*The XML element names (related to classNames, not attribute names) only serve to provide a syntax, they carry no semantics, and are not used in determining the semantics of the artefact content.
 
*The XML element names (related to classNames, not attribute names) only serve to provide a syntax, they carry no semantics, and are not used in determining the semantics of the artefact content.
 +
 +
(Peter Hendler): If it comes true it would make communication between RIM based applications a lot less trouble.  As you know, our MIF parsers and our meta classes add a lot of complexity to the reference Java SIG API and if we could just send messages already based on the RIM backbone that would be fantastic.  If we wanted we could include the clone class names (optionally) as attributes.  We wouldn't need them to process the messages and put them into a database but maybe they'd be nice for readability.  Some humans might rather see "PrednisoneAdministration" rather than "ACT", but since they go into the ACT table the processing would be much easier if the message contained the information that a "PrednisoneAdministration" was a kind of ACT and belonged in the ACT table.
  
 
==Transformation between the XML ITS R1 and the newly proposed RS XML ITS (MS-RS cell transition)==
 
==Transformation between the XML ITS R1 and the newly proposed RS XML ITS (MS-RS cell transition)==
 +
*to match the rim object graph to a specific rim model (i.e. an HMD) (which is required to serialise in that form), you must match the elements to the model by running validation in reverse - it is this kind of association because it meets the constraints that this association has. And you need the MIF for that, of course

Revision as of 06:42, 3 February 2009

The RIM based ITS (or RS XML ITS, a term used by the RIMBAA WG) is an ITS that is based on 'pure RIM semantics', i.e. an ITS that defines an XML syntax which allows for the XML to be processed solely based on its contents (and not on Class Clone names, or knowledge of templates/interactions used).

We currently have the XML ITS R1. It has the following properties:

  • element names identify Rim clone classes
  • properties that are defaulted in the Rim specific model (CIM) are not represented in the instance
  • the order of associations in the instance is fixed for predictability - based on element names
  • whether something is play or scoper etc is implicit (in the rim specific model) rather than in the instance
  • You need the MIF to convert from the instance to a general RIM graph.

The RIM serialization would have different properties:

  • element names identify the RIM back bone associations
  • properties that are defaulted in the general rim are not represented in the instance
    • Almost all structured attributes (e.g. classCode, moodCode) will be present in all instances
  • the order of the associations is irrelevant: only their semantics matter
  • player/scoper etc is explicit in the instance

Analysis

Characteristics of instances that conform to this ITS

  • The XML element names (related to classNames, not attribute names) only serve to provide a syntax, they carry no semantics, and are not used in determining the semantics of the artefact content.

(Peter Hendler): If it comes true it would make communication between RIM based applications a lot less trouble. As you know, our MIF parsers and our meta classes add a lot of complexity to the reference Java SIG API and if we could just send messages already based on the RIM backbone that would be fantastic. If we wanted we could include the clone class names (optionally) as attributes. We wouldn't need them to process the messages and put them into a database but maybe they'd be nice for readability. Some humans might rather see "PrednisoneAdministration" rather than "ACT", but since they go into the ACT table the processing would be much easier if the message contained the information that a "PrednisoneAdministration" was a kind of ACT and belonged in the ACT table.

Transformation between the XML ITS R1 and the newly proposed RS XML ITS (MS-RS cell transition)

  • to match the rim object graph to a specific rim model (i.e. an HMD) (which is required to serialise in that form), you must match the elements to the model by running validation in reverse - it is this kind of association because it meets the constraints that this association has. And you need the MIF for that, of course