Hi Erik,
Response to 2, the Ocean EhrGate Web Service provides a ResultSet as defined
in the following WSDAL fragment:
<xs:complexType name="ResultSet">
<xs:sequence>
<xs:element minOccurs="0" name="name" type="xs:string" />
<xs:element name="totalResults" type="xs:int" />
<xs:element minOccurs="0" maxOccurs="unbounded" name="columns"
nillable="true">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="path"
type="xs:string" />
<xs:element minOccurs="0" name="name"
type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="rows">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded"
name="row">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0"
maxOccurs="unbounded" name="items" nillable="true" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
I am very interested in the idea of basing a query result class on the
ITEM_TABLE class for consistency reasons, however ITEM_TABLE cannot be used
directly because it is limited to rows of ELEMENTs. A query result class
needs to support rows of ANY items as is the case above.
In addition, it may also be necessary to have a query result class that is
based on the ITEM_TREE class to support more complex hierarchical query
results that are difficult to unambiguously represent using a traditional
table structure, which requires cross-join logic to be applied as mentioned
recently (sorry we have not had time to respond to that post, day-job
priorities).
Heath
-----Original Message-----
From: [email protected]
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall
Sent: Tuesday, September 30, 2008 6:35 PM
To: For openEHR technical discussions
Subject: AQL-parser in Java? + AQL response format (using the AS operator)
Hi!
1. Has anybody planned, or started, to create an AQL-parser in Java?
Maybe the basics from AQL to parse tree could be common for several
different persistence implementations and then the rest of the
implementation will be different for different persistence mechanisms.
Our first interest will be in transforming AQL queries to queries
against an XML-database containing versioned Compositions. (It's for
an educational system where performance isn't crucial.)
2. Are there any suggestions for standardised response formats? It
would be interesting if we could query each others' implementations
(Python and various Java based ones) and interpret the response :-)
When returning entire openEHR subtrees (an entire Composition or Entry
for example) I guess the current XML-format could be used to start
with. The response is likely to often be a list of such subtrees and
the format of that list Would need to be standardised.
Another case is when using the AS operator, how do we in a
standardised way identify the named parts.
Best regards,
Erik Sundvall
erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
