Current XQuery implementation issues

[Vasil Vasilev <va...@abv.bg>]

Hi All,

You can take a look at http://issues.apache.org/jira/browse/TUSCANY-1536
for a list of current issues with the XQuery implementation.

For issues 1 and 6 a wrote an e-mail to the Saxon mailing list and I am waiting for an answer.

For the other issues:
2. I need the data type of the input and output of the data that go into and out of the XQueryInvoker be of the Saxon data type. That's why I need to set the data binding in some way from the side of the XQueryInvoker. What I am not sure is if this is the right way, or is this more a hack to do it?
3. I didn't have the time to do it, but generally it is possible to be done.
4. I would like to know if a can use some kind of context, which is associated with given request and if I can use this context to put some data there. I do not want this context to be transferred in web service invocation for example, but only in the chain of transformers to the target invoker.
5. This limitation is again due to the fact I didn't have time to implement it.
7, and 8 - are just questions if somebody knows is this the right way to do it.

Another thing that we should think about is whether it is useful to provide a scope for the XQuery implementation. Currently it is not scoped.

Bye, Vasil

-----------------------------------------------------------------
Познай победителя във Формула 1 и спечели награда! 
http://www.clubf1.net/

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

Re: Current XQuery implementation issues

[Jean-Sebastien Delfino <js...@apache.org>]

Hi Vasil,

Some comments, answers, and more questions :) inline.

Vasil Vasilev wrote:
> Hi All,
>
> You can take a look at http://issues.apache.org/jira/browse/TUSCANY-1536
> for a list of current issues with the XQuery implementation.
>
> For issues 1 and 6 a wrote an e-mail to the Saxon mailing list and I am waiting for an answer.
>
> For the other issues:
> 2. I need the data type of the input and output of the data that go into and out of the XQueryInvoker be of the Saxon data type. That's why I need to set the data binding in some way from the side of the XQueryInvoker. What I am not sure is if this is the right way, or is this more a hack to do it?
>   

What you're describing sounds right to me. The general idea is that an 
implementation should be able to tag the interface it's providing or 
requiring with a particular databinding (because the implementation 
logic wants that particular databinding, or because the technology 
you're using in your implementation extension works with that 
databinding, Saxon in your case).

I'd be interested in your feedback and whether you think it's easy 
enough to do, or if it feels more like a hack :)

You also mentioned in the JIRA that you had to make the interface 
remotable. There may be an issue with the Tuscany databinding framework 
here, I'd imagine that it you had a string of XQuery components (all 
using the same Saxon binding), you'd probably not want to have to mark 
their interfaces remotable.

Raymond, what do you think? Isn't that an issue? why couldn't this work 
with a local interface as well?

> 3. I didn't have the time to do it, but generally it is possible to be done.
>   

Yes I'd think so. It looks like a good thing to do as I guess most 
XQuery component developers will work with XSDs and will probably 
interact with Web Services as well.

Some may even say that they only care about XML and don't want to have 
to deal with any Java code or Java interface :)

> 4. I would like to know if a can use some kind of context, which is associated with given request and if I can use this context to put some data there. I do not want this context to be transferred in web service invocation for example, but only in the chain of transformers to the target invoker.
>   

We may be able to extend the Tuscany Message or EndpointReference to 
carry extra context data, but could you give me a little more background 
on what kind of data you'd like to pass or keep around, and how it's 
going to be used?

In the JIRA you mentioned "which configuration is associated with an 
invocation"... The message carrying an invocation should have pointers 
to assembly model representing the from (reference) and target 
(service), from which I think you could navigate to the binding model 
and its configuration. Is that the kind of configuration you're looking 
for? or some other configuration?

> 5. This limitation is again due to the fact I didn't have time to implement it.
>   

Ok, time is always too short :)

> 7, and 8 - are just questions if somebody knows is this the right way to do it.
>   

For 7, are you talking about Web Services? or is it an assumption you 
made in the XQuery component?

(8) looks like bug, we should create a JIRA for it.

> Another thing that we should think about is whether it is useful to provide a scope for the XQuery implementation. Currently it is not scoped.
>
>   

Ah interesting, I'm not an XQuery expert :) so do you have an example 
showing the kind of state that an XQuery component could support?

Are you thinking about keeping variables around across multiple 
invocations of the same component?

Thanks...

> Bye, Vasil
>
> -----------------------------------------------------------------
> Познай победителя във Формула 1 и спечели награда! 
> http://www.clubf1.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>   


-- 
Jean-Sebastien


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