Difference between revisions of "Datatypes R2 Issue 7"
(→Status) |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
== 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. | + | ? 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 == | == 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) | ||
| + | |||
| + | BOF: no | ||
| + | Add Priority INT to EN, AD, TEL | ||
| + | |||
| + | == Disposition == | ||
| + | |||
| + | Motion in INM 2 May 2007: | ||
| + | |||
| + | We reject this due to insufficient use cases. Gunther / Lee 9-0-0 | ||
| + | |||
| + | == Status == | ||
| + | |||
| + | Rejected | ||
== Links == | == Links == | ||
Back to [[Data Types R2 issues]] | Back to [[Data Types R2 issues]] | ||
Latest revision as of 06:10, 3 May 2007
Contents
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
Motion in INM 2 May 2007:
We reject this due to insufficient use cases. Gunther / Lee 9-0-0
Status
Rejected
Links
Back to Data Types R2 issues
