RE: Problem with resolution of Issue 221

I have a somewhat deeper concern with the scenario that Elliotte suggests: 
 it's not really SOAP. 

Let's say the server responds with a SOAP message that contains a 
mustUnderstand='true' header that changes the semantic of the response 
(I.e. changes it relative to the meaning without the header.)  For 
example, maybe it specifies that all currency is in Mexican Pesos (ah, 
remember that example Andrew?)  If the stylesheet doesn't pick up that 
essential fact, it might format numbers as French Francs or US Dollars. An 
XForms processor is not in general a SOAP processor.  It will not 
necessarily realize that it does not understand the essential header, and 
will proceed to extract data from the message using the stylesheet. 
mustUnderstand headers are perhaps the key feature of SOAP, and this 
scenario appears to completely ignore them.    Similarly, if the response 
was a SOAP fault, would we expect that to include a stylesheet PI that 
would help the XForm processor to do the right thing?

I believe that the architecturally stronger way to enable XForms to deal 
with SOAP responses is to put (lightweight) SOAP processors into the 
clients, use the SOAP model to determine the nature of the message (e.g. 
Fault or not), use the SOAP model to determine which headers are destined 
for that client endpoint and which not, and make the resulting data 
available for XForms processing in whatever manner is deemed appropriate 
(there are lots of Infoset-based approaches one could imagine, but I'm not 
an XForms expert and doubt that I could do a reasonable job in the few 
minutes available just now.)

In short:  SOAP messages are intended to be processed by SOAP-conforming 
software agents.  Once you decide on that, I think the value of things 
like stylesheet PIs goes down significantly.  Again, I'm semi-neutral on 
the PI question, but I'm quite strongly opposed to pulling semantically 
important information out of a SOAP message using means that bypass the 
SOAP processing model. 

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Andrew Layman" <andrewl@microsoft.com>
Sent by: xml-dist-app-request@w3.org
09/03/2002 02:10 PM

 
        To:     <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: Problem with resolution of Issue 221



The scenario described below (SOAP message formatted for presentation to
a client) seems attractive, but there is an aspect of it that I do not
understand: Would the server take into account the language local and
device characteristics of the user agent?  If not, how would the server
select the appropriate style sheet?  If so, however, why not just serve
HTML?  What am I overlooking?

-----Original Message-----
From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu] 
Sent: Tuesday, September 03, 2002 9:33 AM
To: noah_mendelsohn@us.ibm.com; asirv@webmethods.com
Cc: xml-dist-app@w3.org
Subject: RE: Problem with resolution of Issue 221


At 11:02 AM -0400 9/3/02, noah_mendelsohn@us.ibm.com wrote:

>(Finally, I can't help asking what I've asked before:  why is it in
>general interesting to do presentation stylings...which is the normal
>purpose of the XSL PI...on a SOAP message?  SOAP messages are generally
>machine-to-machine.  Whatever the other merits of the PI arguments,
>letting a SOAP message say "here's how to format me for the screen"
seems
>just slightly more interesting than letting an IP packet say the same
>thing.  Maybe I'm wrong and people really do want to send back browser
>screens as SOAP messages with XSL PI's, but it doesn't seem to be a
very
>important goal.   Also, it potentially breaks the mustUnderstand, node
>targeting and other processing that would make such use of SOAP
>interesting in the first place.)
>

Here's one scenario that I think is practical:

1. Server side developers use a SOAP toolkit to expose a local API. 
They are not coding the complete SOAP process by hand using DOM or 
some such. They are not working at the level of XML, at least for the 
most part. Thus, it is *not* trivial to write a separate process to 
expose the data as HTMl through a servlet, or a CGI, or a JSP.

2. Client side developers define an XForm that sends the request to 
the SOAP server, and receives the SOAP response. This allows end 
users to fill in the parameters of the SOAP request using a form, and 
get the result back. If the result contains an xml-stylesheet PI, 
then they can comfortably read the response.

Note that this may not be the only client for the SOAP service. There 
may well be other clients that do not involve an end-user. These 
clients can ignore the PI.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

Received on Tuesday, 3 September 2002 18:27:00 UTC