tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amita Vadhavkar" <amita.vadhav...@gmail.com>
Subject [DAS] XQuery-DAS
Date Mon, 26 Mar 2007 12:48:04 GMT
Hi All,
I am trying to create a prototype for supporting XQuery-DAS. Below are
some points I have gathered so far.
Please give your comments, add to the points.

1) Basic Features that can be supported:-
>>Need to support associating path expression to xml data source.

>>Parameter passing in path expression

>>Support for FLWOR expressions - use of parameters, data source name

>>JOIN operation will involve multiple data sources and multiple expressions
- need to support association
for same.

>>Support for XQuery update facility

2) Places where  current das config/code needs to be modified:-
>>Provide flexibility in config to support RDB/XQUery/xyz...Can have
expansion to
current config.xsd to support multiple connections of multiple types? like

>>Command - needs to take care of associating multiple data sources with
multiple expressions
say, in RDB - its select from t1, t2...
in XQuery - the FLWOR - we can say books.xml <-> expr1, stores.xml <-> expr2
and have a JOIN.

>>Getting connection to data store - should be in Interface-Impl , not
directly in impl- like
it is currently there in DASImpl not in DAS, to keep it generic.

>>graph building related classes should also have separation of interface
and implementation.

3) What can be kept for in-future and what is MUST for the first cut:-
Need comments from you all.

4) Questions:-
>>In RDB-DAS we do not support connection to multiple databases. Even
JIRA-952 talks
only about multiple schemas. Is there any requirement for this/ constraint
due to which
we need to stick to single database?

>>Also, in future, there can be mix of data stores, RDB, XQuery, .... What
are the pros/cons
for supporting connection to multiple different types of datastores
(like one RDB compliant, one XQuery compliant)

5) Link from ML - [DAS] Refactoring DAS to allow multiple implementatons
During the attempt to separate APIs from Impl, we can now decide on the
approach and structure the design.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message