Difference between revisions of "Query recursion"
Rene spronk (talk | contribs) |
|||
| Line 7: | Line 7: | ||
:recursion may be an option (although it may allow for monstruous queries that are effectively non implementable..) Suggest to also have a look at option 3 using a new "blue" relationship class that in itself need not have an attributes instead of the COMP act relationship or an act based CMET (in short: when in blue class country, stick to existing and/or new blue classes). If this is turned into a proposal you'd have to show how the RIM would have to be changed... [[User:Rene spronk|Rene spronk]] 11:19, 15 Jun 2006 (CDT) | :recursion may be an option (although it may allow for monstruous queries that are effectively non implementable..) Suggest to also have a look at option 3 using a new "blue" relationship class that in itself need not have an attributes instead of the COMP act relationship or an act based CMET (in short: when in blue class country, stick to existing and/or new blue classes). If this is turned into a proposal you'd have to show how the RIM would have to be changed... [[User:Rene spronk|Rene spronk]] 11:19, 15 Jun 2006 (CDT) | ||
| + | |||
| + | :You say, "It is the nested logical statements which pose a problem as the query mechanism does not allow for recursion (i.e. a RelationalExpression cannot have a component which is a RelationalExpression)." I don't understand. You nest using LogicalExpression. I don't see what it is that you can't do [[User:Grahame Grieve|Grahame Grieve]] 18 Jun 2006 (CDT) | ||
Revision as of 11:39, 18 June 2006
Within the Choose and Book domain of the NHS CFH project, a requirement has been identified to allow dynamic recursion of queries. The topic was raised at the HL7 UK Infrastructure meeting on June 14th, 2006 and the consensus of those present at that meeting was that the current query mechanism is not sufficiently flexible to do what Choose and Book message designers need it to do.
A Query Modelling Presentation was given at the UK Infrastructure meeting, and includes a summary of the business requirements, an explanation of why we believe the current mechanism doesn't work, and our proposed solution - namely introducing the concepts of choice boxes and recursion to the query mechanism in order to dynamically process nested queries (examples are given in the presentation).
Comments/questions/suggestions on regarding this modelling problem are requested and would be gratefully received either here on the Wiki or via the message lists.
- recursion may be an option (although it may allow for monstruous queries that are effectively non implementable..) Suggest to also have a look at option 3 using a new "blue" relationship class that in itself need not have an attributes instead of the COMP act relationship or an act based CMET (in short: when in blue class country, stick to existing and/or new blue classes). If this is turned into a proposal you'd have to show how the RIM would have to be changed... Rene spronk 11:19, 15 Jun 2006 (CDT)
- You say, "It is the nested logical statements which pose a problem as the query mechanism does not allow for recursion (i.e. a RelationalExpression cannot have a component which is a RelationalExpression)." I don't understand. You nest using LogicalExpression. I don't see what it is that you can't do Grahame Grieve 18 Jun 2006 (CDT)
