This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Datatypes R2 Issue 7"

From HL7Wiki
Jump to navigation Jump to search
Line 2: Line 2:
  
 
== Introduction ==
 
== Introduction ==
 +
 +
Introduce the concept of “partially sorted” lists
 +
There are use cases where a set of elements *can* be ordered, but will not always be so.  In other cases, the relative order of some of the elements will be known, but the order of others will be indeterminate.  It is important to be able to indicate the position information as it is known or not known
 +
 +
? backward compatible: The change itself is backward compatible.  The introduction of the change into certain RIM attributes and datatype properties may introduce compatibility issues
 +
 +
== Discussion ==
 +
 +
<Not sure how best to represent the semantics.  One approach is a BAG of “sequenced elements”, where a sequenced element is an ANY type extended with a SEQ parameterized type which adds a sequence number.  Another approach is to have a list, where each list element is a bag of elements which are unsorted within that sequence.  The former is likely to align better with the ITS.  Also not sure what sorts of set operations are appropriate/needed here.  Obviously a partially sorted list can’t really have a head or a tail.  It’ll probably look more like a bag.
 +
 +
Suggested relationship would be:
 +
PLIST extends BAG
 +
LIST restricts PLIST>
 +
If we take the first approach defined above, then we need to create a SEQ element we can plop onto all of the items in the SLIST.
 +
Types to be changed include:
 +
AD (should be PLIST<ADXP>)
 +
EN (should be PLIST<ENXP>)
 +
 +
Note that AD currently has an “is not ordered” parameter which we would need to deprecate.  The alternative to moving to PLIST for both of these would be to keep “isNotOrdered” for AD and also add it for EN.
 +
This won’t require RIM changes.  Most places where this will be introduced will be as committee restrictions on existing BAG datatypes.  E.g. BAG<EN> restricted to PLIST<EN> where names may or may not be in order of preference.
 +
  
 
PLIST is to mean a "Partially Ordered List". Not sure why it's needed and how this works. Perhaps the only way to represent that is as a tree structure or by embellishing the enumerated elements with sequence numbers where those can be same for several elements. --[[User:Gschadow|Gschadow]] 01:11, 25 Jun 2006 (CDT)
 
PLIST is to mean a "Partially Ordered List". Not sure why it's needed and how this works. Perhaps the only way to represent that is as a tree structure or by embellishing the enumerated elements with sequence numbers where those can be same for several elements. --[[User:Gschadow|Gschadow]] 01:11, 25 Jun 2006 (CDT)
  
? backward compatible.
+
BOF: no
 +
Add Priority INT to EN, AD, TEL
  
== Discussion ==
+
== Disposition ==
 +
 
 +
== Status ==
 +
 
 +
Proposed
  
 
== Links ==
 
== Links ==
 
Back to [[Data Types R2 issues]]
 
Back to [[Data Types R2 issues]]

Revision as of 03:08, 12 January 2007

Data Types Issue 7: Add PLIST as LIST ancestor

Introduction

Introduce the concept of “partially sorted” lists There are use cases where a set of elements *can* be ordered, but will not always be so. In other cases, the relative order of some of the elements will be known, but the order of others will be indeterminate. It is important to be able to indicate the position information as it is known or not known

? backward compatible: The change itself is backward compatible. The introduction of the change into certain RIM attributes and datatype properties may introduce compatibility issues

Discussion

<Not sure how best to represent the semantics. One approach is a BAG of “sequenced elements”, where a sequenced element is an ANY type extended with a SEQ parameterized type which adds a sequence number. Another approach is to have a list, where each list element is a bag of elements which are unsorted within that sequence. The former is likely to align better with the ITS. Also not sure what sorts of set operations are appropriate/needed here. Obviously a partially sorted list can’t really have a head or a tail. It’ll probably look more like a bag.

Suggested relationship would be: PLIST extends BAG LIST restricts PLIST> If we take the first approach defined above, then we need to create a SEQ element we can plop onto all of the items in the SLIST. Types to be changed include: AD (should be PLIST<ADXP>) EN (should be PLIST<ENXP>)

Note that AD currently has an “is not ordered” parameter which we would need to deprecate. The alternative to moving to PLIST for both of these would be to keep “isNotOrdered” for AD and also add it for EN. This won’t require RIM changes. Most places where this will be introduced will be as committee restrictions on existing BAG datatypes. E.g. BAG<EN> restricted to PLIST<EN> where names may or may not be in order of preference.


PLIST is to mean a "Partially Ordered List". Not sure why it's needed and how this works. Perhaps the only way to represent that is as a tree structure or by embellishing the enumerated elements with sequence numbers where those can be same for several elements. --Gschadow 01:11, 25 Jun 2006 (CDT)

BOF: no Add Priority INT to EN, AD, TEL

Disposition

Status

Proposed

Links

Back to Data Types R2 issues