Datatypes R2 Issue 84

Introduction

We are starting to introduce a number of types that are just flavors - constraints on predefined datatypes. Some are in other proposals. A few datatypes that are effectively flavors already exist (CE, CV).

This proposal is to create a new section in both the abstract and ITS datatypes for datatype flavors. The flavors will be normative, and available for use in other datatypes, the RIM and RIM derived models. They will be clearly labelled as flavors, and defined accordingly. In addition the section will define some aspects of how datatypes flavors are used.

Clarification concerning the relationship between datatype flavors and datatypes specialisation (as defined in localisation refinement etc):

 Flavors that are universally defined can be in xsi:type.
 Some specialization of the standard could make other flavors
 into xsi:type but then would lose interoperability with the
 rest of the world and also conformance.

And Note:

 Flavors can fix values, but never declare default values.

Discussion

Lloyd: I'm comfortable with adding a flavors section. I'm concerned that moving CE and CV into "flavors" will affect backward compatibility. Can we leave the where they were and put them in as flavors that can be applied to CD as well?

see long discussion below between Llord, Gunther and Grahame

Disposition

Vote approving this proposal:

For: Grahame, Gschadow, Lloyd, Lee
Against:
Abstain:

skype

• [12:57:36 PM] Lloyd McKenzie says: Concerned about compatibility issues of CE and CV moving to flavors
• [12:58:13 PM] Grahame Grieve says: also, Datatypes R2 Issue 26 (http://informatics.mayo.edu/wiki/index.php/Datatypes_R2_Issue_26#Discussion), we have new comments on this from Bob, and I am interested in whether we should model narrative at the abstract level
• [12:58:24 PM] Gunther Schadow says: CV, CE, etc. can be discussed there. What would that hurt?
• [12:59:16 PM] Grahame Grieve says: I can't see why it would hurt.
• [1:00:04 PM] Lloyd McKenzie says: It would mean that you couldn't have an xsi:type of CE or CV anymore, only CD
• [1:01:15 PM] Gunther Schadow says: Hm, interesting. It wouldn't even be wrong. But why not allow some flavors to have real names?
• [1:01:23 PM] Gunther Schadow says: ... if only for backward compatibility?
• [1:01:52 PM] Lloyd McKenzie says: That was my proposal - allow CE and CV to be used both ways.
• [1:02:29 PM] Grahame Grieve says: I don't agree with that comment about xsi:type
• [1:02:48 PM] Grahame Grieve says: If the model type is CE, then xsi:type is CE
• [1:03:05 PM] Grahame Grieve says: if the model type is any, then that xsi:type is still CE (if the type is CE)
• [1:03:15 PM] Grahame Grieve says: doesn't matter whether they are flavors or not
• [1:03:26 PM] Grahame Grieve says: it matters how they are used, not how they are defined.
• [1:03:29 PM] Lloyd McKenzie says: But when you reference a flavor, the type is the base datatype. The flavor acts like a template
• [1:03:57 PM] Lloyd McKenzie says: Lots of folks will create flavors. We don't want them all appearing as types
• [1:04:09 PM] Grahame Grieve says: yeah that's true.
• [1:04:16 PM] Lloyd McKenzie says: The type tells the application what it needs to be able to deal with. Flavor is just constraints
• [1:04:35 PM] Grahame Grieve says: CE and CV are just constraints
• [1:05:10 PM] Lloyd McKenzie says: Agreed, and if we were introducing them today, we'd call them flavors and you wouldn't be able to use them in xsi:type. The xsi:type would always be CD
• [1:05:20 PM] Grahame Grieve says: you couldn't use a datatype in place of any unless it is defined in the scope (realm etc) of the model (and only as the model allows too)
• [1:05:34 PM] Lloyd McKenzie says: However, we introduced them 4 years ago, and they're in xsi:type all over the place and I don't think we can go away from that.
• [1:05:40 PM] Grahame Grieve says: you couldn't use a datatype *flavor* in place of any unless it is defined in the scope (realm etc) of the model (and only as the model allows too)
• [1:06:15 PM] Lloyd McKenzie says: If someone declares a datatype flavor, I can ignore it and just process the base type and be perfectly safe
• [1:06:25 PM] Grahame Grieve says: so I don't want to go away from that. But we would want Canada to be able to use flavors in the model and be able to use xsi:type then
• [1:06:38 PM] Grahame Grieve says: I agree - as long as the base type is what is in the model
• [1:06:48 PM] Lloyd McKenzie says: The agreement was that flavors would not go in xsi:type
• [1:06:59 PM] Lloyd McKenzie says: Flavors only go in the templateId thing
• [1:07:20 PM] Grahame Grieve says: yeah, agree, but what's a flavor?
• [1:07:47 PM] Grahame Grieve says: we've generally assumed that flavors are how things are defined, but I'm looking at the Canadian and NHS models, and thinking that this is not the real world
• [1:08:03 PM] Lloyd McKenzie says: Not sure what you mean . . .
• [1:09:11 PM] Grahame Grieve says: well, what we have though is that a thing is a defined as a flavor - it's a property of the thing itself - and therefore it can only be used as a flavor, so it can't go in xsi:type, it goes in specialisationId (or whatever), and isn't used in models directly
• [1:09:45 PM] Grahame Grieve says: but we note that CE and CV are really flavors, and as you point out, they are used in models directly, and go in xsi:type (though I've never seen xsi:type="CE" in an actual instance)
• [1:11:14 PM] Grahame Grieve says: so we can tease the two notions apart, with a definition that allows datatypes to be defined as constrains rather than specializes, and a rule that a datatype constraint can be used in a model directly - which means it becomes the xsi:type - or it can be used as a flavor, when the xsi:type is still what the model says, and specialisationId is what the flavor is.
• [1:11:48 PM] Grahame Grieve says: And since ANY is not nailed down, unless the model otherwise specifies, ANY can only be substituted by the types that are in scope in the definition of the model
• [1:19:16 PM] Gunther Schadow says: too complicated
• [1:19:20 PM] Lloyd McKenzie says: Fundamentally, we're better off saying that flavors can't be in type. That makes things nice and simple for parsing applications. However, I think we'll need to grandfather CE and CV
• [1:20:32 PM] Dale Nelson says: xsi:type="CE" was/is used all over the place in Observation.value for general observations whose type is determined by Observation.code. This is especially true in some of the public health case notification models.
• [1:20:43 PM] Grahame Grieve says: don't think it's too complicated. Making the rule and grandfathering CE and CV won't help either, as lot's of other flavors will often be used as types
• [1:21:06 PM] Lloyd McKenzie says: There's no reason they NEED to be used as types
• [1:22:06 PM] Grahame Grieve says: I think so. Let's say that you have a Canadian model (DIM) that has a act.text with type set ot ED.Image
• [1:22:21 PM] Grahame Grieve says: Then you have an RMIM with the same.
• [1:22:35 PM] Grahame Grieve says: is xsi:type ED? or ED.image?
• [1:22:45 PM] Lloyd McKenzie says: I will constrain the model to say ED.Image. And the schema will say ED and schematron will say ED.Image
• [1:23:17 PM] Grahame Grieve says: now lets say that you derive another RMIM from the DIM, and set the type of Act.text to ST, since it's a valid substitution for ED?
• [1:23:45 PM] Gunther Schadow says: Yes, no more ST, only ED :)
• [1:24:27 PM] Gunther Schadow says: I think the people who hate v3dt will hate it even more after that :)
• [1:24:55 PM] Gunther Schadow says: The use of xsi:type="CV" is that you can instantiate a simple implementation.
• [1:25:49 PM] Lloyd McKenzie says: Sigh. No, I'm not recommending getting rid of ST as a type. I don't think most people think of it as being a flavor. And I think the CEN folks would rightfully freak out on us if we did
• [1:26:53 PM] Gunther Schadow says: When v3dt says that CD is at the root of the hierarchy and CE, CV are specializations (something Thomas Beale hates and all the CEN poeple with hiim) it was done because logic requires it. BUT, it never implied that you couldn't implement it by putting a CV implementation at the root and extending it to make CE, CD, etc.
• [1:27:30 PM] Grahame Grieve says: that's an entirely different issue - not one to talk about now
• [1:27:32 PM] Gunther Schadow says: In that implementation (which BTW JavaSIG does too), it is useful to see xsi:type="CV", because then I can instantiate the simpler type.
• [1:28:09 PM] Gunther Schadow says: Same for ST, ED.
• [1:28:18 PM] Dale Nelson says: I kinda like tyhe CV + extension rather than CD + restriction
• [1:28:31 PM] Gunther Schadow says: Even if people don't think of ST as a flavor, it is a constraint on ED and hence a flavor.
• [1:28:57 PM] Gunther Schadow says: So, the key is to see the two directions of specialization as complementary
• [1:29:47 PM] Gunther Schadow says: General type (CD. ED) and specialized restrictions (CV, ST) is for logic and semantics, and to explain substitution. But ...
• [1:30:47 PM] Gunther Schadow says: ... simple type (CV, ST) and more complex extension (CD, ED) is for implementation (what those guys call "normal OO" |-()
• [1:31:15 PM] Gunther Schadow says: And to pick a simple implementation, an xsi:type can be useful.
• [1:31:43 PM] Grahame Grieve says: sure. but none of this is the issue
• [1:31:45 PM] Gunther Schadow says: Of course, I am now talking myself into the templateId thing which I fight against on all other fronts... :^)
• [1:32:02 PM] Gunther Schadow says: I think it has a lot to do with the issue, Grahame.
• [1:32:13 PM] Gunther Schadow says: But tell me again what is the issue?
• [1:34:05 PM] Grahame Grieve says: the issue is, if we called CE and CD flavors, does that have any implications regarding their current use? When does a defined type become a flavor? is it like templates - it's how they are applied? Or is it inherent in the definition?
• [1:35:20 PM] Gunther Schadow says: How would it be "inherent in the definition"?
• [1:38:07 PM] Gunther Schadow says: or, how would it not be inherent?
• [1:38:35 PM] Gunther Schadow says: If I say "a CV is a CD without qualifiers or translations" then it is inherent in the definition of CV.
• [1:40:23 PM] Grahame Grieve says: yes, but if we call it a "flavor" does this automatically mean that you can't use it in xsi:type, you have to use CD?
• [1:40:40 PM] Grahame Grieve says: or are the rules relating to xsi:type about how the CV definition is used
• [1:41:07 PM] Gunther Schadow says: I suppose there are some practical answers to some questions: ST cannot be just a flavor of ED because ST binds fixed values to media-type. That fixed value is not mentioned in the instance. Hence if I have to say xsi:type="ED" and send an ST, then you don't know that media-type is fixed to text/plain.
• [1:41:09 PM] Grahame Grieve says: I propose that simply calling a type a "flavor" doesn't mean that it cannot appear in xsi:type. But you call my rules "too complicated".
• [1:41:16 PM] Grahame Grieve says: though I can see why you do that
• [1:42:19 PM] Gunther Schadow says: But CV and CE do not bind such fixed values, so, they could still be flavors.
• [1:42:34 PM] Lloyd McKenzie says: Flavors not defined universally definitely CANNOT be used in xsi:type. That would totally violate chances for interoperability
• [1:43:02 PM] Gunther Schadow says: Grahame, I agree with you, just because it is called a "flavor" need not mean it can't be mentioned in xsi:type. What I found too complicated was the verbiage around it.
• [1:43:23 PM] Lloyd McKenzie says: We could differentiate between international flavors and say some can be xsi:type. Or we can just grandfather CE and CV
• [1:43:41 PM] Gunther Schadow says: So, it's not whether it's a flavor or not, it's whether the flavor is known universally. Makes sense.
• [1:45:45 PM] Grahame Grieve says: yes, we could allow universal flavors to be used as types
• [1:46:13 PM] Grahame Grieve says: but what about realm models - then you get back to my definition, though not necessarily my off the cuff verbiage (I'm a little hurt ;)
• [1:46:57 PM] Gunther Schadow says: Sorry Grahame, I did inded think now that that was what you had said, somehow.
• [1:47:35 PM] Gunther Schadow says: Biut I am suspicious of "realm"-talk. Reminds me of the vocab TC. ;)
• [1:47:55 PM] Gunther Schadow says: I don't believe in realms.
• [1:48:11 PM] Gunther Schadow says: Information does not want borders.
• [1:48:39 PM] Grahame Grieve says: but people want borders. And people trump information!
• [1:49:11 PM] Grahame Grieve says: since information itself doesn't actually perform ballot responses
• [1:49:18 PM] Gunther Schadow says: But it's unrealistic. People buy Agilent and Cerner in Germany, and Siemens in US and GB.
• [1:49:26 PM] Gunther Schadow says: There are no real borders.
• [1:50:09 PM] Lloyd McKenzie says: There are definitely borders
• [1:51:04 PM] Lloyd McKenzie says: There are specific architectures for implementations in Canada, UK Netherlands and likely other areas
• [1:51:11 PM] Lloyd McKenzie says: That means differences in constraints
• [1:51:56 PM] Grahame Grieve says: yes, the horse has already bolted. and it's had children to the 3rd generation. Localisation means very local indeed, and information is not free
• [1:52:20 PM] Gunther Schadow says: Most issues set up as "realm" issues are not about real needs in countries. They are an attempt at dividing the specification to have smaller consensus groups. Each differences established in real-fiefdoms has little to do with any genuine difference in that country but more with the throught leaders who happen to be there.
• [1:52:55 PM] Grahame Grieve says: I have to agree with that. But I also have to say, so what?
• [1:53:01 PM] Lloyd McKenzie says: Fundamentally, there are differences in approach driven by how healthcare works and the level of agreement that can be achieved
• [1:53:51 PM] Lloyd McKenzie says: There are significant differences between Canada and the U.S. In Canada, we have primary jurisdictional payers who are willing to manage centralized repositories of active data
• [1:54:19 PM] Lloyd McKenzie says: That kind of vision will be extremely hard to achieve in the U.S. Thus a document-based architecture makes more sense there, despite the constraints it imposes.
• [1:54:33 PM] Lloyd McKenzie says: It's just the way the two countries work.
• [1:54:57 PM] Lloyd McKenzie says: It's not about introducing constraints to produce fiefdoms. It's about getting as close to full plug-and-play as possible.
• [1:56:01 PM] Gunther Schadow says: There may be differences on such broad architectual levels, but that does not perculate down into details of data type flavore. I don't think the normal pedestrian at HL7 can stomach all that realm and value-set domeain binding stuff. Enough that they have to put up with this when it comes to vocabulary. I don't like to introduce that into data types any more than absolutely necessary.
• [1:56:27 PM] Lloyd McKenzie says: We set constraints for lengths to ensure interoperability
• [1:56:39 PM] Gunther Schadow says: Bad idea.
• [1:56:44 PM] Grahame Grieve says: well, like elsewhere, the only other choice is to actually agree on everything universally. Not always practical
• [1:56:49 PM] Lloyd McKenzie says: I know that's your opinion
• [1:57:22 PM] Gunther Schadow says: Length constraints can't be made to work as soon as reality defies your constraint.
• [1:57:36 PM] Gunther Schadow says: Anyway ... back to practical issues.
• [1:58:11 PM] Gunther Schadow says: So, flavors that are universally defined can be in xsi:type.
• [1:58:46 PM] Gunther Schadow says: Some specialization of the standard could make other flavors into xsi:type but then would lose interoperability with the rest of the world.
• [1:59:41 PM] Grahame Grieve says: nice summary. I will copy that into the proposaland archive this chat at the bottom of it
• [2:01:00 PM] Gunther Schadow says: There are pure constraint flavors and there are specializations that fix some properties to default values. The ones that fix (or declare defaults) must be cited in xsi:type or else the default would take no effect.
• [2:01:11 PM] Gunther Schadow says: I think we would not call them "flavors".
• [2:01:16 PM] Lloyd McKenzie says: I would be stronger and say that non-universal flavors cannot be in xsi:type if they're going to be compliant
• [2:01:19 PM] Grahame Grieve says: hah. no we're getting controversial
• [2:01:55 PM] Gunther Schadow says: I like Lloyd's stronger notion. It's simpler, less realmy.
• [2:02:25 PM] Grahame Grieve says: I'd rather way:
• [2:03:05 PM] Grahame Grieve says: non-universal flavors can only be in xsi:type if the model is also defined in same context as the flavors
• [2:03:26 PM] Grahame Grieve says: the fact is that the model is defined in the context of a realm, then universal interoperability is already lost.
• [2:03:31 PM] Grahame Grieve says: my opinion anyway
• [2:03:32 PM] Lloyd McKenzie says: No reason to allow that
• [2:03:35 PM] Gunther Schadow says: too complicated ;)
• [2:03:39 PM] Grahame Grieve says: NHS would want that
• [2:03:46 PM] Lloyd McKenzie says: NHS wants lots of things
• [2:03:55 PM] Lloyd McKenzie says: Doesn't mean we need to give it to them . . . :)
• [2:04:16 PM] Lloyd McKenzie says: Fundamentally, they can accomplish what they need whether they use xsi:type or not
• [2:04:19 PM] Grahame Grieve says: sure. But it would be real simple if the types in the model become types in xsi:type
• [2:04:29 PM] Lloyd McKenzie says: Putting it in xsi:type eliminates any chance of interoperability with anyone else
• [2:04:42 PM] Lloyd McKenzie says: V3 at it's core is about interoperability
• [2:04:48 PM] Grahame Grieve says: I would argue that that is already eliminated
• [2:04:51 PM] Lloyd McKenzie says: I'm happy for constraints by realm
• [2:05:04 PM] Lloyd McKenzie says: I'm not happy for customizations that break interoperability
• [2:06:26 PM] Gunther Schadow says: To finish that other thought: Flavor can never declare defaults or fixed values, a CV.SNOMED where codeSystem defaults to SNOMED cannot be a flavor.
• [2:07:01 PM] Lloyd McKenzie says: They can declare defaults or fixed values, but not remove the requirement to express them in instances.
• [2:07:21 PM] Lloyd McKenzie says: I.e. You can say "this must be SNOMED-CT", but can't say "so you can skip sending the codeSystem OID"
• [2:08:14 PM] Gunther Schadow says: Right. That's what I meant. And that's what default means. So, Agree with you they can "fix" but they can never make default. Default means always you don't have to mention it explicitly.
• [2:01:00 PM] Gunther Schadow says: There are pure constraint flavors and there are specializations that fix some properties to default values. The ones that fix (or declare defaults) must be cited in xsi:type or else the default would take no effect.
• [2:01:11 PM] Gunther Schadow says: I think we would not call them "flavors".
• [2:01:16 PM] Lloyd McKenzie says: I would be stronger and say that non-universal flavors cannot be in xsi:type if they're going to be compliant
• [2:01:19 PM] Grahame Grieve says: hah. no we're getting controversial
• [2:01:55 PM] Gunther Schadow says: I like Lloyd's stronger notion. It's simpler, less realmy.
• [2:02:25 PM] Grahame Grieve says: I'd rather way:
• [2:03:05 PM] Grahame Grieve says: non-universal flavors can only be in xsi:type if the model is also defined in same context as the flavors
• [2:03:26 PM] Grahame Grieve says: the fact is that the model is defined in the context of a realm, then universal interoperability is already lost.
• [2:03:31 PM] Grahame Grieve says: my opinion anyway
• [2:03:32 PM] Lloyd McKenzie says: No reason to allow that
• [2:03:35 PM] Gunther Schadow says: too complicated ;)
• [2:03:39 PM] Grahame Grieve says: NHS would want that
• [2:03:46 PM] Lloyd McKenzie says: NHS wants lots of things
• [2:03:55 PM] Lloyd McKenzie says: Doesn't mean we need to give it to them . . . :)
• [2:04:16 PM] Lloyd McKenzie says: Fundamentally, they can accomplish what they need whether they use xsi:type or not
• [2:04:19 PM] Grahame Grieve says: sure. But it would be real simple if the types in the model become types in xsi:type
• [2:04:29 PM] Lloyd McKenzie says: Putting it in xsi:type eliminates any chance of interoperability with anyone else
• [2:04:42 PM] Lloyd McKenzie says: V3 at it's core is about interoperability
• [2:04:48 PM] Grahame Grieve says: I would argue that that is already eliminated
• [2:04:51 PM] Lloyd McKenzie says: I'm happy for constraints by realm
• [2:05:04 PM] Lloyd McKenzie says: I'm not happy for customizations that break interoperability
• [2:06:26 PM] Gunther Schadow says: To finish that other thought: Flavor can never declare defaults or fixed values, a CV.SNOMED where codeSystem defaults to SNOMED cannot be a flavor.
• [2:07:01 PM] Lloyd McKenzie says: They can declare defaults or fixed values, but not remove the requirement to express them in instances.
• [2:07:21 PM] Lloyd McKenzie says: I.e. You can say "this must be SNOMED-CT", but can't say "so you can skip sending the codeSystem OID"
• [2:08:14 PM] Gunther Schadow says: Right. That's what I meant. And that's what default means. So, Agree with you they can "fix" but they can never make default. Default means always you don't have to mention it explicitly.
• [2:08:42 PM] Lloyd McKenzie says: agree