Thank you for the mail.  On closer examination, the Working
Group believes this is not so much a comment on the Last Call
Working Draft as a simple question, and so we are marking it
Resolved.

The answer to the question is:  it's implementation-dependent
which URI schemes an implementation can support in result
documents.  There is nothing in the spec, that is, which says
a processor may not support stylesheets like your example,
and also nothing which requires them to do so.  

In passing, one member of the WG observed that even if a 
processor does support your example, you may not want to do
things that way -- the XSLT processor may support sending
the document to the service, but presumably you'll want to
know what response the service sent back, which result-document
is not going to handle.

Please let us know if you agree with this resolution of your 
issue, by adding a comment to the issue record and changing 
the Status of the issue to Closed. Or, if you do not agree 
with this resolution, please add a comment explaining why. 
If you wish to appeal the WG's decision to the Director, then 
also change the Status of the record to Reopened. If you wish 
to record your dissent, but do not wish to appeal the decision 
to the Director, then change the status of the record to 
Closed. If we do not hear from you in the next two weeks, 
we will assume you agree with the WG decision.

Thanks again.

> but presumably you'll want to
> know what response the service sent back, which result-document
> is not going to handle.


The thing I need is the return value from "result-document".
-----

I try to make most of my software with xslt und try to reduce the
procedural part of my software. 

The procedural part of the software is written in PHP, JAVA, Python ...
and generates XML to feed the XSLT.

---

I try an approach where the input of the stylesheet is a XML message, generates 
by XFORMS (or other clients). 

The XML received from the Browser (XFROMS) may look like:

(<soap ...>
..)
<command name="callWebservice">
<webservice-url>http://xy.com/webservice/weather.xyz</webservice-url>
<parameter>
   <city>Vienna</city>
   <country>austria</country>	
</parameter>
</command>
(..
</soap>)

Without having an extended "result-document" functionality I have to process
the Browser request for example with DOM.

Old method:
parse XML, connect to webservice, give XML to XSLT for styling 

desired method:
XFORMS gives data directly to XSLT, XSLT makes the connection to the webservice
und produces a designed webpage.

It should also be possible to make more than one connection to webservices with one
Stylesheet.

I have a picture in my mind that XSLT is able to convert AND ROUTE XML messages.
This is very easy to implement in XSLT-Processors.

----

With XSLT 1.0 I did some tests using the "document" function to make the same thing:
...

<xsl:variable name="weather">
http://xy.com/getservice?location=<xsl:value-of
select="//city"/>&country=<xsl:value-of select="//coutnry"/>
</xsl:variable>

<xsl:apply-templates select="exsl:node-set(document($weather))"
mode="svgWeatherMap"/>
...

The problem with this method is, that it is not possible to use webservices.
To do everything with GET variables is ugly.

-------------

The procedural part of the software is reduced to:

---snip---
#/bin/sh
xsltproc weather.xslt /dev/stdin
---snap---

########################################################
# All I need is a return value from "result-document". #
########################################################

In combination with webservices or jabber protocol (http pull JEP-0124), XSLT could 
be used as a complete
programming language for websites (or maybe XAML applications).

The security of XSLT is not influenced. With the "document" function it is already 
possible (processor dependent) to contact maschines in the Internet.

----
Sorry for the late input.
Maybe in the new functions of XSLT 2.0 there is already a way to that, but I
couldn't
find one jet.

Thanx for reading.

Bernhard Zwischenbrugger
FH St. Pölten 
http://www.fh-stpoelten.ac.at

You say:

>The thing I need is the return value from "result-document".

What do you expect this return value to be?

If the return value is the content of the constructed document, you can use
xsl:document instead of xsl:result-document.

If the return value is the result of sending the document to some external
service and getting a response, then you can construct the document using
xsl:document, pass it to the external service using an extension function that
invokes that service, and process the result of the extension function.

The purpose of xsl:result-document is to produce the final output of the
stylesheet, but you seem to have some other purpose in mind.

Michael Kay (personal response)

Response sent to MHK by the originator:

>>The thing I need is the return value from "result-document".
>
> What do you expect this return value to be?

The xml message produced by the webservice.
Google example:
http://lamp.fh-stpoelten.ac.at/ss2004/beispiele/googleapi3/result.xml

It should give the return value like "copy-of".

>
> If the return value is the content of the constructed document, you can use
> xsl:document instead of xsl:result-document.
>
> If the return value is the result of sending the document to some
external service and getting a response, then you can construct the
document using xsl:document, pass it to the external service using an
extension function that
> invokes that service, and process the result of the extension function.

Sorry, I don't understand this. I'm good in XSLT 1.0 but didn't read the
complete XSLT 2.0 draft.
(I read the ISBN 1-861003-12-9 ;-)

>
> The purpose of xsl:result-document is to produce the final output of the
stylesheet, but you seem to have some other purpose in mind.
>

Don't know.
I had some limitations with xslt 1.0.
The functionality I missed in XSLT 1.0 was to send http-put
messages to webservices.
In XSLT 2.0 I searching for a method to do that und thought this
must by an extension to the exsl:document method.
Maybe there is a possibility already spezified in XPATH 2.0 or
XSLT 2.0, but I couldn't find this.

thanx


Bernhard Zwischenbrugger

Thanks for the comment.

The WG has taken the view in the past that passing data to a web service and
getting a response is no different from calling a Java method and getting a
response. There's a general mechanism for calling external services, namely the
extension function mechanism, and it's up to product implementors to decide
which kinds of external service they want to provide access to.

Michael Kay 

Hi again

> The WG has taken the view in the past that passing data to a web service and
> getting a response is no different from calling a Java method and getting a
> response. 

<enthusiasm>

XML and HTTP messaging is different from rmi, rpc, or low level udp/tcp
communication or Java.
XSLT is good in managing XML based data. But xslt can't handle biniary data.
XML based messaging ins sometimes difficult to do in languages like PHP. 

XSLT can procede XML based Data from webserices, xml-rpc, (rss already works)

http is build-in in every XSLT Engine I know.

</enthusiasm>



It is implemetation dependend weater the "document-result" makes a connection
to the internet. 

---snip---
<xsl:result-document href="http://api.google.com/search/beta2"
format="toc-format" validation="strict">
---snap---

The http potocoll WILL respond to the POST/PUT request.
In the draft I can't find the answer where this response goes (if the http
functionality is implemented and allowed).
It also isn't clear if this request will be a POST or PUT (if not the same) action.


If the result-document functionality is used simple to write files to the
filesystem 
or to stdout there will not be much response. 
But http will give an answer to requestes.

If you write something about this answer to the draft I would be very happy.
(if it is a good answer ;-)
Please don't send this answer to nirvana - it is useful.

Bernhard Zwischenbrugger

Responding to your off-list request for a progress report on this: we didn't get
round to revisiting it formally at the XSL WG meetings this week, but we will of
course do so. We did have some informal discussion on the topic. I think that
what you're asking for is essentially a mechanism for invoking web services from
XSLT code. We don't think that's part of the job of xsl:result-document, we
think it's essentially another kind of function call. Those members who were
present at the discussion seemed inclined to the view that the current mechanism
for extension function calls should be adequate to enable vendors to provide the
facility if they think there is a user demand, and that this kind of
implementation experience is desirable before trying to standardize anything.

However, this is informal feedback only and does not attempt to prejudge the
final response that the WG will provide. Please be aware that such final
responses can take weeks or months.

Michael Kay

Hi Michael

Thank you very much for information!

> We did have some informal discussion on the topic. I think
> that
> what you're asking for is essentially a mechanism for invoking web
services from
> XSLT code.

If the term "web sevices" isn't reduced to SOAP that's correct.

> We don't think that's part of the job of xsl:result-document,
> we
> think it's essentially another kind of function call.

I did lots of work with SAP Business Connector.
Calling a Business Connector "function" is sending RFC-XML, IDoc-XML,
BAPI-XML, BizTalk or SOAP to BC.

The work is always the same. receiving XML, convert the XML , send XML.
(Or convert, send,  receive, convert, send, receive, ...)

I don't really understand what the difference is between
o sending XML to a http-server
o sending an XML to the file system
o calling a webservice.

For me it is the same.

If I send a 1000 lines BAPI-XML to SAP Business Connector, is it calling
a remote function or sending a document to an URL?

> Those members who
> were
> present at the discussion seemed inclined to the view that the current
mechanism
> for extension function calls should be adequate to enable vendors to
provide the
> facility if they think there is a user demand, and that this kind of
implementation experience is desirable before trying to standardize anything.

(of course I disagree completely ;-)

The sockets already exists in various forms and are used in daily
business.
Also XSLT can be used as a socket for http/xml.
An Apache Module could look like:
http://example.com/xslt-app/calendar.xslt?param1=2004&param2=dec

If xslt can connect to webservices the process can look like:
stdin(xforms delivers xml)-->XSLT-->stdout(xhtml)

The plug is missing. I'm not at all a good programmer.
I don't know why, but the only programming language I was able to learn,
is XSLT. The only possibility for me is to influence standards ;-)

In XSLT 1.0 nobody at W3C thought about this:
---snip---
<xsl:apply-templates
select="exsl:node-set(document($http_url))//elementXY" mode="content"/>
---snap---

In XQuery this is now the FIRST usecase in:
http://www.w3.org/TR/2005/WD-xquery-use-cases-20050404/

(still reduced to HTTP-GET parameters)
---------
Some new W3C Standards use HTTP-POST to send XML (cgi stdin).
XForms, SVG (postURL), SOAP, (AJAX);
SAP has this things;
B2B Communication works this way;
This are the things I have to do with in daily business.


-----
Here are some visuals:
http://lamp2.fh-stpoelten.ac.at/~lbz/xslt2.0/
(needs Adobe SVG 3.0)
---
BTW: If I try to write a file to the filesystem but don't have the
permissions - where does the error go? Is it possible to transform this
error message to html, svg, ...? (is the error message in XML Format?)



thanks

Bernhard

The difference between xsl:result-document and an external function call is that
an external function call returns a result that the stylesheet can process,
while xsl:result-document returns no result (other than possibly causing the
transformation to fail if the result cannot be written).

I think you are trying to extend XSLT beyond its current scope. The job of XSLT
is to transform input trees into result trees. That's one component in an
end-to-end XML application. Other jobs, such as calling web services or
accessing XML databases, are better done by other components, and the job of
tying the whole application together belongs with things such as pipeline
processing languages.

Michael Kay (personal response)

Extract from XSL WG minutes of 9 June 2005:

Action: Sharon will respond to commenter. - Note: action completed 9
June 2005 at 4:11pm ET

Again thank you for your thoughtful comments on the use of XSLT.  The WG again 
considered your request and we are not able to make this change.  I believe 
that we understand your position and frankly, I am sympathetic, to your 
request; however, we cannot spend any more cycles discussing this problem 
without seriously jeopardizing progression of XSLT 2.0 to recommendation 
status.  Thank you for your interest in XSLT.