[
Lists Home |
Date Index |
Thread Index
]
Grahame,
Thanks for the very insightful response.
> Well, the definitions have to exist somewhere. I don't know
> why it makes any difference whether they are data types or
> other constructs, they are still constructs you have to deal
> with and understand
>
True enough. My issue is (as you rightly get to below) when type-restricted
datatypes get incorporated into other HL7 specs in the form of schema
constraints, (like CDA, my main interest) the multiple levels of wrapping
and restriction complicate instance creation. You're quite right to stick to
the principle that to communicate at all, the sender and receiver need to
share an understanding about the data format. I just think (me, coming from
the CDA side) that understanding should be minimally "hard-wired" into other
HL7 standards in a way that ties implemeters' hands.
> I'm not particularly of the view that constrained data types
> will appear in the schemas as new flavors of data types. As a
> matter of fact, I think that if we had a good constraint
> mechanism, and we used it well, we could reduce the number of
> data types. I believe that the main reason we wish to have
> constraints is for documentation, not validation. But we will
> seek to have a formalism to allow validation.
> Likely formalism languages are RDF/OWL, OCL and XPath, not schema
Hooray!! This I totally agree with. I think we need some constraining
mechanism that is "orthogonal" to the datatype schema type definitions.
>
> I agree about the size of the V3 schemas. But this is nothing
> to do with how many data types there is, and everything to do
> with the size of the domain. Have you used the V2 schemas?
> they're not small either
Granted. I'm being a little provovative here, in part because I agree so
strongly with your previous point.
> As for complex types by composition rather than restriction,
> I understand your feelings about this, but this is a decision
> made a long time ago - that V3 would be implemented by
> restriction, not composition. It has it weaknesses, but it
> also has it's strengths. Many people seem to believe that the
> complexity arises from the restriction, but I don't believe
> this is the case.
I think some of this goes on though. My thorn-in-the-side example in the CDA
world is the number of child types of CE (coded value). I think the many
variously constrained CE child types are an attempt to "square the circle"
in a way that better would have been left alone.
> Actually, I think that problem is that developers seem to
> think that V3 data types and RIM classes/processes should/do
> map directly to 3GL code types and routines
This is also a completely fair comment. HL7 can't be expected to do
developer's work for them.
>
> I think the primary design flaw in HL7 V3 is the lack of modularity.
Amen.
Cheers, John
|
