[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
[ 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.
[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1536) Implementation type for XQuery
[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
