[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Doing HTTP/POST from XSLT is fun!

Subject: Re: Doing HTTP/POST from XSLT is fun!
From: Mike Brown <mike@xxxxxxxx>
Date: Mon, 2 Dec 2002 18:56:47 -0700 (MST)
accessing post variables
Gunther Schadow wrote:
> I wasn't really aware of exslt:document, and after reading
> its definition on exslt.org, I am still not clear if it really
> does what I need. What you may not have noticed was that my
> post:message is one round-trip communication and I use it
> as in:
> 
>     <xsl:variable name="response">
>        <post:message url="...">
>           <post:with-param name="SOAPAction" select="'order'"/>
>           <order>Gimme beer.</order>
>        </post:message>
>     </xsl:variable>

My understanding of exsl:document is that if you used it in that context
(instead of post:message), $response would be a copy of the node-set for the
document you created. In other words, it would be your request, not the
response. So you wouldn't have access to the response.

Also, it's apparently left to the implementation to figure out how to "output"
to a particular URI. There's no requirement that it be a POST operation in the
case of an http-scheme URI; certainly, PUT would be more appropriate anyway.

Strictly speaking, POST means "apply the entity in the body of this HTTP
message to the existing handler resource at the requested URI". PUT, on the
other hand, means "store the entity in the body of this HTTP message at the
requested URI, if you can" and warrants a 201 Created (if a new resource was
created), 200 OK or 204 No Content (if an existing resource was modified), or
an error response.

The layer that you refer to as "parameters" is an application-level matter, in
effect only when the Content-Type is one of the two that were intended for
transmitting form input from an HTML user agent.

The HTML form data mechanism has of course been pressed into service for
non-HTML oriented uses of HTTP, but it's probably not safe to assume that any
implementation of exsl:document would support anything more complicated than

  PUT /foo/out.xml HTTP/1.1
  Content-Type: application/xml
  Content-Length: 86

  <?xml version="1.0" encoding="utf-8"?>
  <greeting xml:lang="en">hello world</greeting>

when called like this:

<exsl:document xmlns:exsl="http://exslt.org/common"
  href="http://myserver/foo/out.xml"
  method="xml"
  encoding="utf-8"
>
  <greeting xml:lang="en">hello world</greeting>
</exsl:document>


> if not, is there a change that this might be added to this
> exsl:document specification?

> Also, IMPLEMENTATIONS in http://www.exslt.org/exsl/elements/document/
> says that libxslt from Daniel Veillard (where did I hear that name :-)
> is the only thing that supports it?

4XSLT (from 4Suite 0.12.0, currently approaching beta status) does, but we
only support URIs with the "file" scheme.

> Looks like exsl:document is somewhat similar to xsl:result-document
> in XSLT v2.0.

I believe the intent is the same, yes.

I think your custom extension element is the best approach for what you want; 
it's the only way you can control the behavior well enough to make it POST, 
send the right data in the post, and generate nodes that give you some 
indication of the response / result of the post.

Mike

-- 
  Mike J. Brown   |  http://skew.org/~mike/resume/
  Denver, CO, USA |  http://skew.org/xml/

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.