You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Raymond Feng (JIRA)" <tu...@ws.apache.org> on 2007/09/16 09:52:32 UTC

[jira] Resolved: (TUSCANY-1536) Implementation type for XQuery

     [ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raymond Feng resolved TUSCANY-1536.
-----------------------------------

    Resolution: Fixed

Patch applied under r576059. Vasil, thank you for the contribution.

> Implementation type for XQuery
> ------------------------------
>
>                 Key: TUSCANY-1536
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1536
>             Project: Tuscany
>          Issue Type: New Feature
>          Components: Java SCA Misc Implementation Extensions
>            Reporter: Vasil Janov Vasilev
>            Assignee: Raymond Feng
>            Priority: Minor
>             Fix For: Java-SCA-Next
>
>         Attachments: changes_14_09_2007.tar.gz, changes_27_08_2007.tar.gz, saxon_fixes_letter.txt, xquery_impl.tar.gz
>
>
> An implementation type for components written using the XQuery script.
> Some notes about this prototype:
> 1. I see XQuery as a mighty data integration technology, that's why, in my
> opinion, the SCA specification should be enhanced with XQuery-related
> implementation type.
> 2. In order to prove this concept I created simple extension to Tuscany,
> which interprets implementation type "implementation.xquery". Generally
> the following contributions were done:
>  - xquery artifact resolver
>  - xquery implementation provider
>  - Saxon data binding and transormes for DOM Nodes and SDO DataObjects
> 3. As underlying implementation Saxon B is used. This has its
> limitations - it is not schema aware, but it is free (MPL - licensed).
> 4. I created test cases for the following scenarios:
>  - Sending data from one SCA component to XQuery component
>  - Feeding data to XQuery component by using properties
>  - Binding XQuery component as a web service
>  - referencing other SCA components from the XQuery component
> 5. In order to allow integration of XQuery in SCA I have also provided
> some specification of how references, services and properties can be
> defined in the XQuery file (see examples).
> The prototype is not ready to checkin, i.e. for example: it is not formated, there are no all needed 
> unit tests, it is not made runnable with Maven, i.e. it is compilable with Eclipse (I have used Eclipse 3.2)
> It consists of the following projects (you can find them in the attachment)
> - tuscany-implementation-xquery - provides the xquery implementation
> - tuscany-databinding-saxon - provides saxon-related databindings and transformations
> - sample-quote-xquery - integration scenario for the prototype
> - saxon-lib - the saxon libraries
> This prototype has the following limitations - as currently seen by me:
> 1. The Saxon should be enhanced so that one can set external variables (of Object type) when making single function call
> 2. Currently in create of XQueryImplementationProvider I set data bindings for the services and references. In order to have a data transformer later, all these
>    references and services should be with remotable interfaces, so that their original bindings are set. Is this the correct way to do it? Or may be I
>    should provide my own binding (not databinding, but binding)?
> 3. Limitation - only Java interfaces can be implemented by XQuery implementations
> 4. Is there any way to say which configuration is associated with a given invocation? Currently NodeInfo objects are transformed from one configuration to another which has performance impact. I.e. can I associate an object with an invocaion in some kind of context?
> 5. Limitation: currently the result of XQuery cane be only a single item, not a collection
> 6. Saxon B can not interpret XML documents in which there are namespace declarations. This requires conversion, which is a step that increases memory overhead and speed
> 7. For DataObjects transformation, it is presupposed that that their starting element is the name of the implemented interface with its first letter made to lower case. Is this the best variant?
> 8. Why I can not invoke directly from the client a component with data binding, i.e. why the self reference can not contain Data transformation interceptor?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org