Tim Cook schreef: > Hi All, > > I have watched this thread with great interest. My first question is; > Why? > > Why is there such an interest in developing a specific persistence layer > API for openEHR? I think that this is an area where we should encourage > many implementations to follow their own ideas and then we can discover > which works best for this type of information. Some may believe that > the Node + Path approach on the wiki is right, others may select an XML > database like eXist. My Python implementation will use a native object > database. > > The *important* thing is that they all be able to respond to EHR > Queries. IMHO the thing that we need to examine and discuss is the > completeness and correctness of EQL. > > So maybe what Bert is advocating is discussion of a persistence model > for his Java implementation? > Yes this is true, I am advocating a persistence layer-API that can connect to A java-implementation. Not *MY* model, but *A* model, in fact, a transparent layer. Why?
Sorry to repeat myself. The most important reason (amongst others) is that a defined API would speed up the development of more implementations, also other architectures could benefit from this. At this moment, there is hardly a market for OpenEhr, a market needs products, a market with only a few products does not invite people to come and look. An well defined API would facilitate other developers, would facilitate a growing market and demand for OpenEhr. (Many standard-definers like to mention implementors of their standard to prove the importance of their standard. The more people that use it, implement it, sell it, buy it, love it or even hate it -> ->The more people will have heard about it, have an opportunity to pay attention to the advocates, generate business, implement it, decide for it.) In my opinion, a good, transparant API supports many database-architectures, object/relational, just (XML)files.... whatever It hides the database-technique for the upper layers. (This is a often used definition for the term API, like WIndows, it does not need to know which hardware specs you follow, as long as your driver connects to the API Windows has for this purpose) In OpenEhr, in my humble opinion, this means, a persistence-API enables the kernel objects to save their selves, it does not tell them how to save their selves, below the API can be database-related code, or again another abstraction-layer, that is not important. On the upper side homes the kernel, how can this connect to an API, are there any modifications needed to connect, which modifications are best, etc.... Do the kernel objects save their selves, or is there a visitor-pattern which enables them to save, or another pattern, related to archetype-parsing-structs, Discuss what is best, that is the purpose of defining an API and build it. An API-definition van possibly dictate/demand some contructs to be done in the kernel itself. There is also need for another API, that is the services-API, this is needed for other software to connect to the openehr system. Maybe this is also not considered as being an essential part of OpenEhr (as Thomas put it), but it is also needed, and I am sure many will benefit from it if this will be discussed in public. There is more to say about this, but the danger is big that I will be repeating myself even more without any result. Repeating is not a problem, that is a normal process in advocating an idea, so now it is time to stop doing, some people may get bored, and no one seems to catch on. Bert
