Reading your post I have remembered something I have read sometimes but I haven't still gotten a satisfactory answer: If UML and ADL are that similar, why don't we use both? What does UML can express that ADL can not express that makes some people to dislike it (and also what can ADL express that UML can not express that makes some people to dislike it) I get that UML could be complicated, but again I don't think nobody expects someone to model a concept in UML without the right tools
2010/11/9 Grahame Grieve <grahame at kestral.com.au>: > hi Tom >> The only kind of 'profile' I know of elsewhere in other standards is of >> the kind 'we only implement x, y but not z'. > > which is the kind I'm talking about > >> The answers Grahame gave me last time I discussed how to profile >> 21090 for 13606 use are here, about half-way down. > > rather incomplete. We really do have to get this done > >> I happen to know that Sweden, Singapore and the UK have created at least 3 >> different 'profiles' of 21090 over time, all to suit their own needs. There >> is no guarantee that data or software built on these home-grown profiles >> will talk to each other, nor that any of them would talk with software or >> data built on the pure 21090 specification. > > but if they've profiled according to the method above, then they will talk to > each to the degree that their requirements match. Solving mismatched > requirements is outside the scope of a data types standard. > > If they've profiled *and mapped*, then it's not so straight forward - depends > very much on the quality of the mapping. > >> This can't be anybody's idea of an easy way to get started with a data types >> standard. > > no, of course, the easy way, is "do it my way", which is a variation of the > Not-Invented-Here-Syndrome > >> There is no escaping from the fact that having a type called 'Any' >> representing a concept that should be called something like 'AnyDataValue' >> (in openEHR it is DV_ANY) is annoying and has to be dealt with in some way. > > really? You've not heard of namespacing? It would make that much difference > to you to prefix all or some of the types with "DV_" or something? Surely not. > Did you read the discussion in ISO 21090 about this point? (It was written > specifically for you) (and btw, in my implementation, I did end up prefixing > the names, for purely programming reasons) > >> We had this discussion last week. I made the point that this is >> true of IT vertical industry integration standards. I don't believe >> Tom offered a counter example to this. >> >> I have not been tracking other vertical industry ICT standards. But I did >> offer a examples of 'stacks' of standards which do not follow the strange >> world of HL7 modelling. Everyone else uses normal OO modelling, or else >> something accepted like XML schema (admittedly terrible for object models, >> but that's another story); but HL7 can't (it instead tries to get OMG to >> change UML).? I fail to see why standards in e-health have to be done in >> such a bizarre way. There is nothing special about e-health requiring that. > > you changed the sense. Your original claim was that standards should just > pick something that works well enough. My point is that ICT vertical > interoperability standards don't work like that, including in health. > > As Ann pointed out, not everyone uses normal OO modelling, and for > a variety of reasons. In fact, big companies are starting to move on - have > you seen M (microsoft oslo)? > > I happen to think that design by constraint - which is the fundamental > pattern of both v3 and openEHR - is irretrievably busted, and it's time > for us both to move on and find something better. (But perhaps we should > spend some time implementing in the real world before we do that...) > > I'm watching M closely to see if a realistic alternative emerges there. > It hasn't yet. And the alternative is to talk to OMG to talk about getting > UML changed. But it's odd to have the pot call the kettle black, since > ADL is hardly standard UML. > > Heath: > >> As an ISO standard, I believe that it should be an intersection of all the >> input specifications, rather than a union > > extension has it's own difficulties, as does union. We were aware of the > berlin decision, but ISO 21090 resulted from a deliberate decision > to do something different. Was that a right decision? Unfortunately, > time won't tell, since the alternatives are purely hypothetical. > > Grahame > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
