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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
