On 22/03/2012 09:34, Seref Arikan wrote: > Hi Pablo, > I do not want to have a discussion about how to implement specs. That > was not my point. Let me try to be more direct: > > Generics causes problems during implementation of openEHR if Java or > XML is involved. Java + XML has a huge user base. Even XML on its own > has a huge user base. > By making a minor change in OO design options, openEHR can eliminate > these problems for everyone using Java and especially XML. > This may help openEHR become a spec easier to implement. > > This is the point I was trying to make. * > *
I am not sure that this is an argument for removing generics though. Lots of people 'use' XML, but they don't model in it - it is unusable for object-oriented modelling. I think most XML schemas are built as a particular data view of an object model, for a particular kind of communication channel. There are obviously going to be many non-XML communication channels in the future, as there already are inside major orgs like Google and Amazon, where binary messaging is being used. And it's easy enough to create an XSD from an object model. It's annoying that XML is too dumb to do things like generics natively, but not the end of the world. As for Java, I don't think we should remove the numerous uses of generics in the model due to Java's poor implementation of them. For example, nearly every LOCATABLE descendant in openEHR (RECORD_COMPONENT descendants in 13606) have some generic declaration, e.g. Cluster.members: List<Item> etc. I don't think creating hardwired classes like ListItem, ListSection, ListEntry, ListParticipation etc is a reasonable option for a clear model. There are a few instances in openEHR of non-container generics, like DvInterval<T: DvOrdered> and so on. I don't really think we should compromise the model here either - the specification says exactly the intended semantics, in a clear and comprehensible way. Instead, I think we should re-invigorate the Java Implementation Technology Spec, that Rong wrote originally some years ago, to provide Java implementation guidance for issues like this. All target implementation technologies have their issues; if we keep hacking the primary specfication model to suit all of them, we will no longer have any clear statement at all of what we really wanted in the first place, and it would in any case probably be a very weak model, once you accommodate no generics, no multiple inheritance, no typing, ....! - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/8e9465da/attachment.html>
