You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Vasil Janov Vasilev (JIRA)" <tu...@ws.apache.org> on 2007/08/14 17:03:32 UTC
[jira] Created: (TUSCANY-1536) Implementation type for XQuery
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
Priority: Minor
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
[jira] Updated: (TUSCANY-1536) Implementation type for XQuery
Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Sebastien Delfino updated TUSCANY-1536:
--------------------------------------------
Patch Info: [Patch Available]
I have created a new JIRA component for the XQuery implementation. Assigning this JIRA to it.
> 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: Jean-Sebastien Delfino
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 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
[jira] Updated: (TUSCANY-1536) Implementation type for XQuery
Posted by "Vasil Janov Vasilev (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasil Janov Vasilev updated TUSCANY-1536:
-----------------------------------------
Attachment: changes_27_08_2007.tar.gz
> 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: Jean-Sebastien Delfino
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 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
[jira] Updated: (TUSCANY-1536) Implementation type for XQuery
Posted by "Vasil Janov Vasilev (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasil Janov Vasilev updated TUSCANY-1536:
-----------------------------------------
Attachment: saxon_fixes_letter.txt
> 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: Jean-Sebastien Delfino
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 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
[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
Posted by "Vasil Janov Vasilev (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523094 ]
Vasil Janov Vasilev commented on TUSCANY-1536:
----------------------------------------------
After I communicated with Michael Kay from Saxonica (See the attached mail for more info) the ollowing appeared for the resolution of issues 1 and 6:
- for issue 1: generally it is not recommended to make a single function call. This is a proprietary API and can not be used with XQJ. So the current situation will not be changed, i.e. i will attach expression extensions for invoking the function
- for issue 6: It appeared that the XQuery script should be updated with the required namespaces of the used types. Corresponding to this I made some chages in the source code, which removed the code for unnecessary removal of prefices and also updated the XQuery scripts. I have attached the changes in the changes_27_08_2007.tar.gz file. Can somebody check them in the repository?
> 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: Jean-Sebastien Delfino
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 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
[jira] Updated: (TUSCANY-1536) Implementation type for XQuery
Posted by "Vasil Janov Vasilev (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasil Janov Vasilev updated TUSCANY-1536:
-----------------------------------------
Attachment: xquery_impl.tar.gz
The XQuery implementation sources as eclipse projects
> 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
> Priority: Minor
> Attachments: 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
[jira] Updated: (TUSCANY-1536) Implementation type for XQuery
Posted by "Vasil Janov Vasilev (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasil Janov Vasilev updated TUSCANY-1536:
-----------------------------------------
Attachment: changes_14_09_2007.tar.gz
> 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: Jean-Sebastien Delfino
> 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
[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
Posted by "Vasil Janov Vasilev (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527584 ]
Vasil Janov Vasilev commented on TUSCANY-1536:
----------------------------------------------
I am attaching a patch, so that the XQuery implementation can work with Saxon 8.7
> 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: Jean-Sebastien Delfino
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 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
[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520172 ]
Jean-Sebastien Delfino commented on TUSCANY-1536:
-------------------------------------------------
I have commited the three modules:
- tuscany-databinding-saxon
- tuscany-implementation-xquery
- sample-quote-xquery
under revision r566530.
Thanks a lot for this great contribution to Tuscany!
> 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: Jean-Sebastien Delfino
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 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
[jira] Assigned: (TUSCANY-1536) Implementation type for XQuery
Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Sebastien Delfino reassigned TUSCANY-1536:
-----------------------------------------------
Assignee: Jean-Sebastien Delfino
> 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: Jean-Sebastien Delfino
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 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
[jira] Resolved: (TUSCANY-1536) Implementation type for XQuery
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ 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
[jira] Assigned: (TUSCANY-1536) Implementation type for XQuery
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raymond Feng reassigned TUSCANY-1536:
-------------------------------------
Assignee: Raymond Feng (was: Jean-Sebastien Delfino)
> 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
[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520173 ]
Jean-Sebastien Delfino commented on TUSCANY-1536:
-------------------------------------------------
I am leaving the JIRA open for now as you have raised interesting design limitations / issues, which still need to be addressed.
> 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: Jean-Sebastien Delfino
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 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
[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523108 ]
Raymond Feng commented on TUSCANY-1536:
---------------------------------------
I'll apply the patch. Thank you.
Raymond
> 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: Jean-Sebastien Delfino
> Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 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