This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Serialization"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | {{MnM | + | {{MnM Resolved Hot Topic}} |
| − | {{Lore}} | + | {{Approved Lore}} |
| − | '''Serialization''' either points to the process of serializing a particular static model - starting with its [[ | + | '''Serialization''' either points to the process of serializing a particular static model - starting with its [[Entry Point]], or to the definition of the method of serializing a static model. |
The serialization method determines the sort order of elements within a static artefact, whenever a serialized expression of the model is needed (e.g. for [[Table View]]s, or as a basis for ITSs) | The serialization method determines the sort order of elements within a static artefact, whenever a serialized expression of the model is needed (e.g. for [[Table View]]s, or as a basis for ITSs) | ||
#The sort order of RIM class attributes is defined in the RIM section of the v3 Edition. The order the attributes appear in the RIM is their official order. The section doesn't explicitely talk about order, it just says "This class has the following attributes". | #The sort order of RIM class attributes is defined in the RIM section of the v3 Edition. The order the attributes appear in the RIM is their official order. The section doesn't explicitely talk about order, it just says "This class has the following attributes". | ||
| − | #The sort order for the data | + | #The sort order for the data type properties is defined in the Abstract Data types specification. The order the datatype properties appear in the abstract datatypes section is their official order. The section doesn't explicitely talk about order, it just says "This datatype has the following properties". |
| − | #The sort order for the associations is defined in a document (namersdocumentation-1[1].0.1.zip, | + | #The sort order for the associations is defined in a document (namersdocumentation-1[1].0.1.zip, http://hl7projects.hl7.nscee.edu/frs/download.php/88/namersdocumentation-1.0.1.zip ) that is available on the GForge site (http://hl7projects.hl7.nscee.edu). |
[[Image:Rim attribute order.jpg|200px|right|thumb|Sort order of RIM class attributes]] | [[Image:Rim attribute order.jpg|200px|right|thumb|Sort order of RIM class attributes]] | ||
| Line 14: | Line 14: | ||
*An ITS may use a different sort order "on the wire". any ITS should use the document order that datatype components are defined in in the abstract datatypes document as the order for the ITS , unless there is good reason for doing otherwise, in which case that reason must be given in the ITS specification. The same should apply to RIM attribute order. Note that there are examples where attribute order may need to be changed in the ITS, e.g. attachmentText is sent after the associations so that the rest of the instance can be processed before the attachments are reached. | *An ITS may use a different sort order "on the wire". any ITS should use the document order that datatype components are defined in in the abstract datatypes document as the order for the ITS , unless there is good reason for doing otherwise, in which case that reason must be given in the ITS specification. The same should apply to RIM attribute order. Note that there are examples where attribute order may need to be changed in the ITS, e.g. attachmentText is sent after the associations so that the rest of the instance can be processed before the attachments are reached. | ||
*Realm aspects: The localization process does not give them the authority to create their own sort orders. | *Realm aspects: The localization process does not give them the authority to create their own sort orders. | ||
| + | |||
| + | == Resolution == | ||
| + | Accept the above as approved lore | ||
| + | 2008/07/25 Lee/Craig 4/0/0 | ||
| + | |||
| + | ''Action'' Reflect this core principles | ||
| + | |||
| + | *The issue that there is currently no normative documentation of the above serialization method was addressed (by Dale, in his role as the scribe of the ITS WG) at Faciliators Roundtable in Orlando (2009-01-15). Action item was re-activated and put on the MnM list; - to include this (as an appendix) in Core Principles. | ||
{{INM Workitem}} | {{INM Workitem}} | ||
Latest revision as of 00:06, 16 January 2009
This page documents a Resolved, but not fully actioned MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
This page documents Approved Lore, i.e. an approved set of facts about a particular subject, but that have not been documented in a ballot yet.
Serialization either points to the process of serializing a particular static model - starting with its Entry Point, or to the definition of the method of serializing a static model.
The serialization method determines the sort order of elements within a static artefact, whenever a serialized expression of the model is needed (e.g. for Table Views, or as a basis for ITSs)
- The sort order of RIM class attributes is defined in the RIM section of the v3 Edition. The order the attributes appear in the RIM is their official order. The section doesn't explicitely talk about order, it just says "This class has the following attributes".
- The sort order for the data type properties is defined in the Abstract Data types specification. The order the datatype properties appear in the abstract datatypes section is their official order. The section doesn't explicitely talk about order, it just says "This datatype has the following properties".
- The sort order for the associations is defined in a document (namersdocumentation-1[1].0.1.zip, http://hl7projects.hl7.nscee.edu/frs/download.php/88/namersdocumentation-1.0.1.zip ) that is available on the GForge site (http://hl7projects.hl7.nscee.edu).
Notes
- The sort order does change on occasion in response to harmonization proposals. Schemas are bound to the sort order as it was for the normative edition declared in the "version" attribute for the schema.
- An ITS may use a different sort order "on the wire". any ITS should use the document order that datatype components are defined in in the abstract datatypes document as the order for the ITS , unless there is good reason for doing otherwise, in which case that reason must be given in the ITS specification. The same should apply to RIM attribute order. Note that there are examples where attribute order may need to be changed in the ITS, e.g. attachmentText is sent after the associations so that the rest of the instance can be processed before the attachments are reached.
- Realm aspects: The localization process does not give them the authority to create their own sort orders.
Resolution
Accept the above as approved lore 2008/07/25 Lee/Craig 4/0/0
Action Reflect this core principles
- The issue that there is currently no normative documentation of the above serialization method was addressed (by Dale, in his role as the scribe of the ITS WG) at Faciliators Roundtable in Orlando (2009-01-15). Action item was re-activated and put on the MnM list; - to include this (as an appendix) in Core Principles.
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.
