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

RE: What does SOAP really add?

• To: "Didier PH Martin" <martind@n...>,<xml-dev@l...>
• Subject: RE: What does SOAP really add?
• From: "Julian Reschke" <julian.reschke@g...>
• Date: Tue, 23 Apr 2002 16:46:36 +0200
• Importance: Normal
• In-reply-to: <016601c1ead3$6d2d2a00$6401a8c0@didierhome>

> From: Didier PH Martin [mailto:martind@n...]
> Sent: Tuesday, April 23, 2002 4:31 PM
> To: Julian Reschke; Bill de hÓra; xml-dev@l...
> Subject: Re:  What does SOAP really add?
>
>
> Hello Julian,
>
> Julian said:
> > Well, there are other URI schemes than HTTP. For instance, FILE.
>
> Didier replies:
> Yes the file protocol can be expressed as a URI as in the
> following example:
> file://c:dir1/dir2/doc.xml. It works well within the context of the actual
> "document" function (but could be a real security threat is not
> using in the
> proper context). Any other protocol expressed as a single URI and
> returning
> an XML document is OK in the current framework.
>
> Now what about all the other ways to obtain an XML document?

I don't understand the question. I just stated that XSLT's document function
itself is not tied to GET -- GET just happens to be the default retrieval
method for HTTP. Whether and what other URI schemes are supported by an XSLT
engine is implementation-specific.

> Julian said:
> > I personally don't think it's an issue at all. As others
> pointed out, POST
> > may have side effects, so I'm not convinced that it is a good idea to do
> it
> > from XSLT.
>
> Didier replies:
> I expected something better than using an external authority argument
> Julian. The simple fact is that if the document function is replaced by
> another construct allowing to do such things as an HTTP POST or any other
> HTTP based functions like for instance a WEBDAV SEARCH method, then if and
> only if the construct is used to fetch an XML document, then, there are no

Wait-a-minute. Just because an HTTP method returns an XML document doesn't
mean that it doesn't have side-effects.

> side effects. The only problem would be to retrieve a document that cannot
> be parsed. This problem is also present with the actual
> "document" function
> anyway. So, the answer is: there are no side effects if the construct is
> doing what was previously stated (i.e. limited to a document fetch)

I think this is a misunderstanding.

For instance, a WebDAV DELETE with depth: infinity may return an XML
document (multistatus), but it certainly has side effects.

> In fact, to be really up to date with the basic web methods, such
> function/construct would be compatible with IETF messages' structure which
> is
>
> method URI
> attribute:value
> ......
> attribute:value
>
> body....
>
> This would allow us to obtain XML documents with WEBDAV, SIP and any other
> in progress internet messages protocols.

I happen to know WebDAV and can tell you that WebDAV's method to obtain a
document is ... GET (WebDAV is just an extension of HTTP).

Now I agree that it would be nice if there was a way to get some of the XML
formatted information that a WebDAV server can offer into XSLT. I can think
of two:

- assign the information a URI on which you can do a GET

- use an XSLT extension function

Julian

• Follow-Ups:
  • Re: What does SOAP really add?
    • From: "Didier PH Martin" <martind@n...>

• References:
  • Re: What does SOAP really add?
    • From: "Didier PH Martin" <martind@n...>

• Prev by Date: Re: What does SOAP really add?
• Next by Date: RE: What does SOAP really add?
• Previous by thread: Re: What does SOAP really add?
• Next by thread: Re: What does SOAP really add?
• Index(es):
  • Date
  • Thread