Hi Amita

Related to the features, I think it's fine to start simple and get
improvements gradatively as we progress...

Some issues that you have identified:
  - Config model more flexible to accommodate differences  between
multiple implementation
  - Factory issues, and the ability to get different implementations
Are already available in my sandbox [1] as part of the work I did to
accommodate multiple DAS implementations [2]

It's probably good idea to keep a XQuery DAS page on the Wiki and keep
updating it with requirements, discussions and design we are taking...

[1] -
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/
[2] - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.html

On 3/26/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

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
RDB/XQuery...

>>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
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.html
During the attempt to separate APIs from Impl, we can now decide on the
approach and structure the design.

Regards,
Amita




--
Luciano Resende
http://people.apache.org/~lresende

Reply via email to