Reflections on Pablo and Leo, both recognizing the complexity of the RM and looking for ways how to deal with it.
On 11/28/2013 04:30 AM, pablo pazos wrote: > Hi Leo, > > I think simplifying openEHR is not a good strategy. The problem is > that most programmers are not implementing against openEHR specs, they > are implementing against other people's implementations. So they have > the learning curve of the specs + the learning curve of using provider > XWZ tools. Hi Pablo, you are talking about tooling, which is one way to approach the complexity-problem. A good way too. Hide the complexity, behind GUI-based tooling. Strong points in your attitude towards OpenEHR is that you recognized the complexity of the RM, and second, that you are making easier the way to work with it. But there can be also more fundamentally ways to handle the complexity and make the learning curve less burdensome. One is, the most important, but not in our hands, make the AOM important, create RM's above the AOM, use it for other purposes than OpenEHR only. The more the AOM is used, the less developers will complain about complexity. But as I said, that is not in our hands. So, what else can we do? Create a substandard which makes entrance to the AOM less complicated. That is what Leo is writing about. I skip some text > > .................... > .................... > .................... > .................... > .................... > > </last_name> > > </person_name> > > </identities> > > </details> > > </person> > > > > which would also be much more efficient to store and index, and lead > to more intuitive xpath > > > > //first_name_part[1]/value/text() (: Jan :) > > //first_name_part[2]/value/text() (: Peter :) > > //last_name_value/value/text() (: Balkenende :) Hi Leo, You advertises a simplification to make the AOM better to work with. This is also an approach, but, simplification means, lost of functionality. And technical arguments like indexing should not weight in innovation. Because when you consider current technical arguments in defining something new, you are not innovating, but you are consolidating. Henry Ford said: If I asked the people what they want, they would say: A faster horse. So think beyond the current boundaries. Do not think of AOM making simpler to remove a learning curve, or solve technical problems, because that is conforming to the present, which is already the past one second later. So think beyond that. That is one of the good things of the designers of OpenEHR, and more, the designers of the side effects, like AOM, which are important beyond the boundary of OpenEHR. Today is thanksgiving? Let us thank those people for their wonderful work which started about in the beginning of this millennium, or even in the end of the previous millennium. They designed an eco-system without having a technical reference to build it. They showed the courage of Henry Ford. They were inventing technical solutions, instead of conforming to technical solutions of the that time current which is now the past. I know, through the years, people struggled a lot with how to implement it. And I know, most of them do not admit that. Every implementor has to solve his own secret problems. OpenEHR is not an open developer-community, but it is a community of entrepreneurs which all want to be the number one. What would have happened if OpenEHR was designed conforming the technical possibilities of 1999, would we still have been talking about it right now? OK, enough of hallelujah. ---------------------------- What's next.... - Tooling is good, but tooling is always situation/platform depending. It is not a fundamental solution. - Simplification in order to solve technical problems is conforming to the past and is not a good way. We need to think deeper about this. I did not get in this any further then the path/value combinations, and insuccession, the short path notation (which makes it in fact more complicated). Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131128/83ee6679/attachment.html>
