I don’t see any transformation needed, only leaf-data are stored as data, and that are always simple data, not objects, there is no transformation needed, no efficiency lost. There are no proven efficiency-problems in XML, that is only a story, from a bad research with lack of details, we had that discussion. The technique is over 15 years an industry-standard for many purposes. But I understand your point, we can discuss that without bashing XML: You are saying that people may want to use another storage than XML-databases, and than they can’t use XQuery. You are right, but can they use AQL? There is only an incomplete definition of AQL in a Wiki, that had no substantial changes since long time, thus hardly any progress. There is no guarantee that the Wiki is stable. I think you know what kind of effort and the risk is to write a new query-engine on a new language-concept for any database-concept of choice. Seref said it to Randolph a few days ago, there isn’t hardly any work done by third parties, only two implementations of AQL, and in the same sentence he calls AQL the almost most important part of the OpenEHR eco-system. Quote of Seref in this context: One could, reading this, starting to doubt if OpenEHR can exist without a query language, I think Seref is right. It cannot. And then there is no stable specification? Also consider this. How can two companies have implemented AQL if there is no stable definition? How much money do they put at stake with uncertain result? These are It brings me to the conclusion that for third parties, there is only one way to go, and that is XML, and XQuery, there is no other way to get an OpenEHR system ready at this time and the coming few years. The query language is one difficult part, the other difficult part is validation. Both can be solved using standard industry-tools, I come back to this at the end of this message. And I am not talking about MLHIM. 
The OpenEHR eco-system for XML is ready and full of features. I don’t say, XML is the only way, to write kernel. But it has many advantages, because of the wide industry-support, and the thousands of man-years development in that. Choosing any other solution means having to write an query engine for a query language which still is not declared stable, and having to write a validation-tool which, as far as I know, only exist for DADL. Implementing OpenEHR for a software-vendor, not using XML, is hardly an option. By chance, tomorrow I go to Intersystems, for a technical introduction for Cache and tooling. I am specially interested in (proprietary) path-based query-formalism they support. I ask them for XQuery-support. I’ve read on their website, it was possible. It is not surprising when their proprietary path-based query-formalism is very much like XPath. This is because how can a serious database-vendor nowadays live without XQuery-support? All big database-vendors support XML-structures, and they also support XQuery. Check Microsoft, check Oracle, XML is here to stay, and that is so since 15 years. XPath2.0 (which is a subset of XQuery 1.0) is very similar to the path-based AQL, easily convertible, as you call it. Maybe not 100% mapping, that can only be said after there is a stable AQL definition, but those from the AQL-Wiki can. I did similar once, writing a virtual query-engine. It was an engine which could query “mapped-to-objects-third-party-likely-structured-databases” (Excusez le mots). It could connect to an old COBOL database, a MUMPS hierarchical database, an API-based database, and some SQL databases. They all could, on this product, be approached over SQL, to a common simplified virtual datamodel. That was the goal, and it worked, more or less. It is about the same you propose in this sentence. Using the grammar coming out of a query-engine to use it on another database-concept with a likely but not the same structure and probably other kind of optimizations. It is very difficult to do something like that. It will cost man-months/years to get it fast performing and more or less bug-free. The easy part, simple selects will take a few months, but then, optimizing in different kind of indexes, also user defined indexes, multi-user, unions, sub-selects, aggregations, authorization. It is not easy at all, and I would definitely not advise a company to go this way. As far as I can see from the Wiki, AQL is not going any advanced way, but it looks very obvious as one can expect from a generic query-language. I don’t know the state of art what Seref is talking about when he says that AQL is implemented by two vendors. Terminology can possibly be done by preprocessing, depending of course on the terminology. No, I mean that it is impossible to represent RM 1.0.2 in W3C XML Schema. It is unusable. You cannot validate any XML-dataset modeled from an CKM archetype against the XSD’s on the OpenEHR website regardless of the XML-Schema-version. It is simply impossible, illegal. OpenEHR is breaking several XML-Schema rules. XML Schema in any version is not ready for multi level modeling. With some tricks it can be done, I do that now, but that is not very elegant. But I have not found any reason why it cannot be defined in RelaxNG, which is a widely used Oasis standard. But, I must admit, I am not completely ready researching this, but I am for more 80%. It relaxes on the points where XML Schema has its blocking restrictions. It looks promising, I will let you know, I think, end next month, when I start working again on this. My goal however is not only to represent OpenEHR in a schema-language, but everything that can be defined in ADL 1.4, so including OpenEHR. And the translation from ADL to schema needs to be done automatically. Oasis, as you will know is an industry standardization organization, it is Domain Member of OMG, and it is also sponsored by OMG (and the members of OMG). There are several RelaxNG schema definitions which made it to ISO-standard, it is stable for many years now. I am sorry to say. Writing a W3C XML Schema representing an archetype, and conforming the base-schema’s published on the OpenEHR website. It is not possible, not even for one single archetype from CKM. So the XSD’s are useless, meaning, there is no way they are useful. The conversion to the exchange-format cannot be validated against a constrained schema representing the archetype in which they are defined. I am pretty sure in this. You know what you have for source-data, maybe objects in Cache, or DADL or path/value-combinations. But you don’t know if the target/exchange XML-data are still valid. You can guess they are, but you cannot proof they will always be valid. I think, validation after data-transforming is very important. A guess should not be good enough. Bert
Speak calmly to it next time. Bert, by this you got my day off to a rollicking start.