Hi All
I have been having a long discussion with Tom off the
list about ISO 21090, and we've come to agreement
about the general picture.
When I teach ISO 21090 tutorials, and I get to the
implementation part, the first thing I say is that the
data types are completely denormalised, and that
I would never implement them as is inside my system
(as anything but an object model for exchange.)
And Tom says that they are all designed wrong
to be used as data types inside a system
We're both saying pretty much the same thing. The
21090 data types are designed, as Stef pointed out,
for *exchange*. Specifically, for exchange between
systems that are otherwise unconnected in any
effective way.
When you use the data types inside a system, then
they aren't so appropriate. Now we have to be careful
about using the term "inside a system" because even
within systems, we have multiple connection/exchange
points. So by "inside a system" I mean, for exchange
between different entities that are connected by a
common architecture that establishes, to a greater
or lesser degree, common infrastructure that is used
to normalise the content.
That normalisation might be
- the 5 normal forms of classical relational databases
- moving audit information away from the content to a
specialised audit/logging functionality
- moving constraint information out of the data into the
system metadata
- re-organising content that has been conflated by
semantic intent to more clearly draw apart
management concerns.
- moving concerns out of the data into the code
There's more, but that list will suffice for now. (so it should be
clear that I am using "normalise" in a somewhat loose
sense).
Tom sees these gaps, and responds negatively, whereas
I just accept them, knowing that they exist, and that I have
plans to deal with them, plans that vary across my different
systems as their architectures change.
But we do both share the concern that the degree to which
the 21090 data types are designed and optimised for
exchange is not understood by casual adopters. It's not that
it's impossible to adapt non-normalised models built for
exchange to serve as system architectures (there's an
active group in HL7 - RIMBAA - doing just that), but that
you need to know that what you are doing is going to
present certain challenges you will need to prepare for.
Users could easily start to implement them in systems and
find themselves later with a series of bad choices that they
could have avoided earlier, and then they'd blame 21090..
It appears that Tom and I may jointly develop a variant
of ISO 21090, that features the same basic semantic
content, but in a format that is suitable for use in systems
rather than for exchange. It will describe clearly how to
interoperate using 21090, but will be suited for system/case
design.
I am a little uncertain, because I am concerned that the
particular normalisations you anticipate will affect the way
that you design such a variant, and I don't see how to
pick a particular set - a logical obvious candidate around
which an implementation community would coalesce. Tom
and I are still talking about that.
Tom and I hope that this explanation will bring some clarity
to any observers who have been left confused by our somewhat
passionate debate to this point 
Grahame
