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
