On 11/28/2013 02:43 PM, pablo pazos wrote: > 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. > > IMO end system developers should not even know about AOM. We can > create stuff that hides that from them and they can just consume APIs > the way they are familiar with, e.g. like they consume Twitter or > Google Maps APIs. I think you misunderstood.
What I wanted to say, if the AOM is used in a wider/broader field then OpenEHR, it is something developers get used to, and because of the broad use they are motivated to get on the learning curve. In my opinion there are several levels of API-possible. One level is semantic rich, like createObservation, then there can be, a bit more generic: createEntry, but it can also be completely generic, like createObject. Depending on the reference model the object can be a Locatable, if it is an OpenEHR or 13606 Reference Model, but as far the AOM concerns, Locatables do not exists. The AOM only knows archetypes, an AOM-instance-structure is created by the ADL-parser, and as the parser eats it, you have a valid AOM-structure. This is a powerful concept, which can be served by a generic API, but what that will look like, I don't know. To overcome acting in the wild, and creating data without predefined structure, archetypes need to conform to a Reference Model. So there is a two way validation needed: One, is the archetype conform the Reference Model? This only is needed at creating time of the archetype. The other is are the data conform the archetype? Many other fine features are also available on base of AOM, like AQL and templates. Anyway, that was what I am thinking about when developers know the AOM. When you have these things organized, you have a generic database-engine on base of the AOM. I think, very powerful concept. But there are some black holes, and one of them is the communication between client and server. As you know, I do it on base of path/value combinations, but many others do it on base of a kind of object-instance-natation, DADL or XML or JSON, or whatever. Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131129/0170ea53/attachment.html>
