Hi Leight,
Leight said:
> Paul Prescod points out that the direct mapping of document('soap://...')
to
> an invication of a SOAP-based web service may not be the best mechanism
for
> hooking the SOAP and the XSLT together, since that puts invocations of the
> web service under control of the XSLT processing model rather than putting
> the results of the SOAP invocation as documents given to XSLT. I believe
> what is needed are specific input-output transformation operations that
are
> orchestration steps producing result documents. These result documents
> could then be named and referred to by XSLT "document('result1')"
> expression, or perhaps by a simple XPath path expression if the results
are
> incorporated back into the document itself.
Didier replies:
If the soap URI is used in the context of the document() function there are
no differences between a URL invocation and a soap's URI invocation. If what
is provided to the XSLT engine is an XML document then this latter is simply
processed by the XSLT engine. No side effects on the client side (i.e. XSLT
engine). In the case if the result is a simple type like a string, a
structure, a number then the protocol handler should extract the returned
the value from the SOAP envelope and encapsulate it in an XML element. I am
not there yet. As I said in Didier's lab report, this will be my next step.
Several options are opened concerning what is passed to the XSLT engine:
a) simply give to the XSLT engine the XML document returned by the SOAP
server
b) if we deal with an RPC call, then extract the SOAP overhead and just
return the returned data as an XML document's fragment
probably other options not yet envisioned and I will have to think more
about it.
By the way, thanks for your comments. I do not know very well XML pipelines
and XLANG. I will read the documents you mentioned.
cheers
Didier PH Martin
