Datatypes R2 Issue 9

Introduction

Clarify the semantics of Set, Bag and List to allow proper determination of allowed substitutions as extensions and restrictions. At present, it’s not clear which “collection types” can be substituted.

? backward compatible. None. (May identify some existing specifications as non-compliant)

MnM

Discussion

Proposed:

SET<T> restricts BAG<T>
LIST<T> restricts PLIST<T> (see other proposal)
PLIST<T> extends BAG<T>

It’d be really helpful if we clarified what the default collection type is for associations too (suggest BAG). Also need to identify how immutability and cardinality apply differently to the collection types than they do to other datatypes.

There is no unique hierarchical relationship between those. What is the use case? --Gschadow 01:13, 25 Jun 2006 (CDT)

BOF: No

Further comments:

• The PLIST proposal was rejected.
• The problem is that substitution is allowed. This does not require any gen/spec relationship
• The semantics are complicated; Even trying to introduce a generic collection ancestor is an exercise in futility.

For the reasons outlined above, I think this should be rejected.--GrahameGrieve 10:21, 3 May 2007 (CDT)

btw note the the MNM hot topic # Datatype Substitution Issues.

There is no unique hierarchical relationship between these. Neither gen/spec nor extends/restticts.

• A LIST is an ordered SET, i.e., a SET of OrderedItem<T>, where OrderedItem<T> specializes T and adds unique order number.
• But a discrete SET is a restriction of LIST where order doesn't matter and where no item can occur more than once.
• A BAG is a discrete SET of BagItem<T>, where BagItem<T> specializes T and adds an item frequency number.
• But a discrete SET is a BAG where the BagItem frequency is restricted to 1.
• A BAG is a LIST where the order does not matter.

Hence, which one is more basic? Which one is derived? Gschadow 10:33, 3 May 2007 (CDT)

Disposition

R2 taskforce Vote #1 Record:

 Reject: Grahame, Gunther
 Continue Discussion:

much discussion ensued on Skype, which lead to the following second vote:

Motion: We reject this proposal. We will await the outcome of the MnM Hot topic referenced above, then add appropriate promotion/demotion relationships to provide formal support for the datatype substitutions that MnM wishes to exist.

For: Grahame, Lee
Against: Lloyd
Abstain:

Status

Proposed

Links

Back to Data Types R2 issues

Archives

[2:25:59 AM] Lloyd McKenzie says: Don't care about gen/spec, do care about extend/restrict
[2:26:26 AM] Grahame Grieve says: why - so what. Leave it to the hot topic, discuss this, and then we can come back to it in a cleaner proposal
[2:26:48 AM] Gunther Schadow says: I will expand on my point that there is no simple extends restrict relationship between them.
[2:26:52 AM] Lloyd McKenzie says: At the moment, we're doing illegal substitutions in the tools
[2:27:00 AM] Lloyd McKenzie says: We're constraining BAG to SET and LIST
[2:27:13 AM] Lloyd McKenzie says: BAG to SET is ok - that's constraining saying no duplicates
[2:27:16 AM] Lee Coller says: Can we take PList out of it
[2:27:21 AM] Lloyd McKenzie says: However BAG to LIST is extending
[2:27:36 AM] Lloyd McKenzie says: Really PLIST can be constrained to BAG or LIST
[2:27:57 AM] Lloyd McKenzie says: A BAG is a PLIST where all items have the same position in the sequence
[2:28:06 AM] Lloyd McKenzie says: A LIST is a PLIST where all the items have distinct positions
[2:28:41 AM] Lloyd McKenzie says: We support PLIST for associations - we allow duplicate sequence numbers to indicate simultaneous.  Same with priorityNumbers
[2:29:17 AM] Lloyd McKenzie says: If we like, we can make PLIST Abstract if we don't think it needs to be concrete
[2:30:41 AM] Lee Coller says: I understand that one can do this on relationships, my objection is that isn't a type we need in HL7 because we handle it other ways.
[2:31:18 AM] Lloyd McKenzie says: I just want our collection hierarchy to work, because right now it doesn't.  If we don't need it concrete, we can make it abstract
[2:32:04 AM] Lee Coller says: I could support it abstract, I now understand what you are arguing.
[2:34:19 AM] Gunther Schadow says: There is no unique hierarchical relationship between these. Neither gen/spec nor extends/restticts. 

   * A LIST is an ordered SET, i.e., a SET of OrderedItem<T>, where OrderedItem<T> specializes T and adds unique order number.
   * But a discrete SET is a restriction of LIST where order doesn't matter and where no item can occur more than once.
   * A BAG is a discrete SET of BagItem<T>, where BagItem<T> specializes T and adds an item frequency number.
   * But a discrete SET is a BAG where the BagItem frequency is restricted to 1.
   * A BAG is a LIST where the order does not matter. 

Hence, which one is more basic? Which one is derived? Gschadow 10:33, 3 May 2007 (CDT)
[2:35:47 AM] Lee Coller says: A list is not an ordered set, by definition a set cannot have repeated elements, a list can.  A list is an ordered BAG.
[2:36:23 AM] Lloyd McKenzie says: Ordering a set implies adding a property able to indicate order.  That's an extension
[2:36:37 AM] Gunther Schadow says: But Lee, a List is an ordered set of Pairs with a unique order number. That way no two pairs are the same.
[2:37:02 AM] Gunther Schadow says: But don't you forget continuous sets!
[2:37:12 AM] Gunther Schadow says: Much of your argument considers only discrete sets.
[2:37:24 AM] Gunther Schadow says: I'm going to add a proposal regarding this.
[2:37:47 AM] Lloyd McKenzie says: It's fine for continuous too.  In a BAG or a LIST, every element in the set (continuous or not) has the same sort order - nominally 1
[2:38:00 AM] Grahame Grieve says: oh no, not another proposal, can we just stick to this one? Or is it really a new idea?
[2:38:15 AM] Lloyd McKenzie says: In theory, bags can have continuous portions too, they can just have the same continuous portion 5 times over if they like
[2:38:46 AM] Lee Coller says: What would be the use case for a bag with continuous portions?
[2:39:29 AM] Lloyd McKenzie says: Didn't say there was a use-case, just that the abstract definition doesn't make it impossible for it to occur
[2:39:41 AM] Gunther Schadow says: None. That's why I am saying that a SET is not a restriction of BAG.
[2:39:55 AM] Gunther Schadow says: I don't understand.
[2:40:05 AM] Lloyd McKenzie says: BAG is un-ordered with no uniqueness constraint
[2:40:13 AM] Lloyd McKenzie says: SET is unordered with a uniqueness constraint
[2:40:16 AM] Gunther Schadow says: A BAG has discrete items.
[2:40:27 AM] Lloyd McKenzie says: I've I want a BAG, and someone sends me a set, I'm happy
[2:40:33 AM] Gunther Schadow says: A SET can have contunuous subsets.
[2:40:40 AM] Lloyd McKenzie says: If I want a SET and someone sends me a bag, I'm not happy
[2:40:44 AM] Gunther Schadow says: No you're not happy!
[2:40:48 AM] Lloyd McKenzie says: Why not?
[2:41:05 AM] Lloyd McKenzie says: BAG operations work perfectly fine if the contents are continuous subsets.
[2:41:19 AM] Gunther Schadow says: Well, I take it back. If you want a BAG of discrete elements and you get a SET, you might be happy, but not really.
[2:41:31 AM] Lloyd McKenzie says: Why not really?
[2:41:47 AM] Grahame Grieve says: I've got to admit, Gunther, I don't see from the abstract set definition why it is any different to SET in regrads to continuous bags
[2:41:48 AM] Gunther Schadow says: Well may be really. For the EN/AD thing it seems to work.
[2:42:03 AM] Grahame Grieve says: I agree that the narrative points the other way
[2:42:04 AM] Gunther Schadow says: What is a continuous bag?
[2:42:19 AM] Grahame Grieve says: the really fun thing about this is how we are screwing Lloyd up and he can't let go
[2:42:22 AM] Lee Coller says: If we fix the equality definition of EN/AD can we get rid of BAG?
[2:42:31 AM] Grahame Grieve says: yes that is another plan
[2:42:41 AM] Grahame Grieve says: no, we want to fix it, but that won't get rid of BAG
[2:42:47 AM] Gunther Schadow says: I'm not sure the equality issue is fixed so easily.
[2:43:15 AM] Lloyd McKenzie says: Side topic.  Side topic.
[2:43:39 AM] Grahame Grieve says: no, that will be an interesting question, but we will have to figure it out because the spec is in error at the moment. anyhow, agree with Lloyd,
side topic, since it won't do away with BAG
[2:43:53 AM] Lloyd McKenzie says: The fundamental thing is that nothing in the definition of BAG says that all contents must be discontinuous
[2:44:11 AM] Grahame Grieve says: -discontinuous- discrete
[2:44:20 AM] Lloyd McKenzie says: right
[2:45:59 AM] Dale Nelson says: so what again is a continous bag?
[2:46:00 AM] Grahame Grieve says: the thing is, I propose to reject this, and revisit a (new) datatype proposal once MnM has ruled on the hot topic. I just think that we can solve this   
by promotion and demotion if we need to, rather than mucking around with the gen/spec relationships
[2:46:06 AM] Gunther Schadow says: must be discrete, yes.
[2:46:28 AM] Grahame Grieve says: well, that is a new proposal - to change the definition of bag to make it clear that it must be dsicrete
[2:46:31 AM] Grahame Grieve says: well, that is a new proposal - to change the definition of bag to make it clear that it must be discrete
[2:46:35 AM] Lloyd McKenzie says: It's not a "continuous bag".  It's a bag containing continuous elements".  If a BAG contains 1..7.5 and 3..20, that's legal
[2:46:39 AM] Gunther Schadow says: I agree with Grahame 100% on the rejection rationale.
[2:46:56 AM] Lee Coller says: I actually agree with Gunther here, there is no inheritance relationship among those three types, at least not as I would do it in a pure OO paradigm
[2:46:57 AM] Lloyd McKenzie says: If we do that, then we can't constrain BAG to SET or SET to BAG
[2:47:05 AM] Lloyd McKenzie says: Everything must be done at the RIM and we're stuck
[2:47:18 AM] Grahame Grieve says: promotion/demotion, promotion/demotion
[2:47:27 AM] Gunther Schadow says: promotion/demotion, promotion/demotion
[2:47:33 AM] Grahame Grieve says: unless you want to take that away. But I don't recommend it
[2:47:41 AM] Gunther Schadow says: neither do I
[2:47:47 AM] Lloyd McKenzie says: promotion/demotion is nice, but methodology is constrain/extend
[2:47:55 AM] Lloyd McKenzie says: You can only constrain, never extend
[2:48:05 AM] Grahame Grieve says: either it's ok or it's not.
[2:48:16 AM] Grahame Grieve says: I'm going to rename the skype chat to "beat up on Lloyd"
[2:48:22 AM] Lloyd McKenzie says: :P
[2:48:46 AM] Lloyd McKenzie says: Fundamentally, SET is a constraint on BAG.  If I send a BAG where something expects a SET, it'll croak
[2:49:07 AM] Dale Nelson says: Only if the bag isnt constrained to a set
[2:49:17 AM] Lloyd McKenzie says: If I send a BAG or a SET where someone expects a LIST, it'll croak
[2:49:38 AM] Lloyd McKenzie says: That means we've got a constraint hierarachy
[2:50:21 AM] Grahame Grieve says: no. note that we are adding a promotion/demotion between SC and ST so you can go backwards. Substitutability does
not constitute evidence for  gen/spec.
[2:51:06 AM] Lloyd McKenzie says: I don't care about gen/spec.  I care about constraint hierarchy
[2:51:38 AM] Lloyd McKenzie says: If at the RIM, I want something to be constrainable to SET, LIST or BAG, then I need a type that can allow that constraint
[2:51:51 AM] Grahame Grieve says: so, let my proposed disposition stand: Let MnM decide what the semantic implications are, and then we'll add the promotion/demotions required, along  with clear documentation about the expectations
[2:52:19 AM] Lee Coller says: The problem is our data type hierarchy in some cases is a constraint hierarchy and in other cases its an extension hierarchy.
[2:52:21 AM] Lloyd McKenzie says: The abstract datatypes needs to make it clear what the substitution rules (whether by gen/spec, promote/demote or some other mechanism)
[2:52:35 AM] Grahame Grieve says: That's another R2 proposal - that one will get up.
[2:52:36 AM] Lloyd McKenzie says: Datatype substitution is ALWAYS constraint
[2:52:48 AM] Lloyd McKenzie says: If someone wants an INT and you give them a REAL, they'll choke
[2:53:06 AM] Grahame Grieve says: fine substitution is always constraint. But constraint is not always gen/spec.
[2:53:38 AM] Lloyd McKenzie says: Fine.  Don't care how you express it, so long as it's clearly expressed
[2:53:49 AM] Lloyd McKenzie says: And we need SLIST to allow constraint to all three
[2:54:00 AM] Lloyd McKenzie says: (for those attributes where it's reasonable to want all 3)
[2:55:32 AM] Lee Coller says: How about COLLECTION?
[2:55:57 AM] Grahame Grieve says: how about it. Bad idea at the abstract level - no need for it. ITS (ISO) has it, but it's only an implementation thing
[2:56:15 AM] Lloyd McKenzie says: SLIST is more accurate in terms of what you can do with it
[2:56:24 AM] Lloyd McKenzie says: If we ever find we need it, then we just make it concrete
[2:56:33 AM] Grahame Grieve says: I have updated the disposition to include a motion I think we can all vote for. Please vote
[2:56:38 AM] Grahame Grieve says: http://informatics.mayo.edu/wiki/index.php/Datatypes_R2_Issue_9#Disposition
[2:56:41 AM] Lloyd McKenzie says: Sorry, meant PLIST, not SLIST
[2:58:59 AM] Lee Coller says: I've voted
[2:59:17 AM] Lloyd McKenzie says: It won't let me in . . .
[2:59:45 AM] Grahame Grieve says: Hmm. It has surprising taste
[3:00:37 AM] Lloyd McKenzie says: I don't agree with rejecting something when we're waiting for a response
[3:00:38 AM] Gunther Schadow says: Guys, I don't think this Skype chat is vaible. It requires constant monitoring.
[3:00:41 AM] Lloyd McKenzie says: Tabling is fine
[3:00:49 AM] Lloyd McKenzie says: Rejection is inappropriate
[3:00:58 AM] Grahame Grieve says: Gunther, got a better idea?
[3:01:11 AM] Grahame Grieve says: back to email?
[3:01:18 AM] Gunther Schadow says: Hear ye, hear ye!
  [12:52:43 PM] Lloyd McKenzie says: Datatype substitution is ALWAYS constraint
  [12:52:55 PM] Lloyd McKenzie says: If someone wants an INT and you give them a REAL, they'll choke
  [12:53:13 PM] Grahame Grieve says: fine substitution is always constraint. But constraint is not always gen/spec.