On 22/04/2013 10:01, Bert Verhees wrote: > On 04/22/2013 10:01 AM, Thomas Beale wrote: >> >> Hi Bert, >> >> Xquery wasn't stable in 2006 when we needed a query language. AQL was >> implemented by Ocean by 2007 and has been working since then, and >> something similar implemented by companies in Brazil. Later on, >> Marand implemented it, and I suspect someone else. > > I am sorry, I have no time to provide a well done analysis, but I have > an opinion. > > XQuery is stabilized in 2007, XPath is sometime longer around, but as > I understand, in version 2.0 it is subset of XQuery 1.0. I am reading > the O'Reilly book of Priscilla Walmsley about XQuery, she explains > very thoroughly (as we are used from her). > > AQL as shown in the Wiki, (that is what I know of AQL), can very well > be served by syntax-transformation to XPath/XQuery. > http://www.openehr.org/wiki/display/spec/Archetype+Query+Language+Description > > Should one do that? Syntax-transformations? There is a risk. > > In favor of XQuery, there are query-engines available almost out of > the box, open source or closed, some which are in development for 10 > years, based on good indexing, and still being active developed. > With all respect, but I think there has been very good work done, > worldwide, and one should profit on that if possible.
that's fine for XML data. But many implementations do not use XML as the storage format - and there are good reasons for that - XML Schema representations of object data require transformation, and have efficiency problems that have to be addressed in one way or another. The general need we have in openEHR is for an abstract query language that can be used to express queries to any openEHR (or 13606 or other archetype-based system), regardless of whether its concrete persistence happens to be in XML. If you are suggesting that we use Xquery/Xpath even for non-XML data representation cases, that's a different conversation. It won't work out of the box, because we use a more efficient path syntax (but which is easily convertible), and Xquery/Xpath make other assumptions due to being targetted to XML, e.g. they assume the XML attribute/element dichotomy, which doesn't exist in normal object data; they don't assume an object inheritance model, and so on. Nevertheless, if it could be shown that AQL could be mapped to a clean subset of Xquery/Xpath as a standard formalism, that's likely to be useful. It would mean that those implementers who choose XML as their internal data representation would be able to use standard products out of the box, as you say. Others might be able to some components, e.g. Xquery parsers in order to build a query engine that talks to non-XML data. > > XQuery can also be used directly to query OpenEHR datasets. I see no > reasons against this very good working solution. There is not really a > need for a separate query-language. > At this moment AQL is a niche and XQuery is a standard. I have read > somewhere that also Cache from Intersystems in an additional module > supports XQuery, but marketing language is often gibberish. One can > never be sure what really is possible. > > Apart from that, maybe there is a wish to complete the > ADL/AQL-eco-system, for those who chose not to store in XML and want > to write their own AQL-query-engine on the database-concept of their > choice. > In that case, AQL should, in my opinion, be defined as close as > possible to XPath/XQuery. I think very very close is possible and even > obvious. > This is, because the basic goal is the same, to offer a generic > query-language. well it's a bit more that that - it's to define a query language that is a) based on the logical content models of the data and b) needs to know nothing about the concrete persistence representation of the data. The query language also has to support terminology-based query expressions and subsumption. But if it can be aligned, let's do it. It just needs someone to do the work. > But other arguments could be: to comfort developers, to profit from > what is already been done (in standard-definition and in tooling), and > to provide interoperability with that part of the world, which > understands XML better than ADL/AQL. > > But the next issue comes up. > > A shortcoming of the OpenEHR-documentation is the expression of the RM > in XML-Schema. Derived OpenEHR-datasets can never be validated legally > in XML-Schema 1.1 or 1.0. Do you mean just that the Release 1.0.2 XSDs need to be better designed? We certainly know that, and welcome any proposals on that (of which there are already many). > So defining the RM in a XML-Schema is quite useless, and bringing > people on a dead end street. There are, however good alternatives, > even better. Not sure what you are saying here, Bert. XML openEHR data is regularly used as an exchange format for applications and systems. Can you explain a bit better what you mean by the above? - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130422/e6eedf83/attachment-0001.html>
