RE: Problem with resolution of Issue 221

OK, just for the record, I am more or less neutral on the PI question, 
except that I would rather not trip over the W3C process and have to spend 
weeks or months going back to last call just to make this one change.  The 
purpose of my note was not to indicate that there are compelling reasons 
for the status quo, but merely to point out that the status quo is far 
from absurd.  It's just a tradeoff IMO.

By the way;  if I were looking for a robust, SOAP-like way to say "style 
this part of the message with that stylesheet", I'd consider making a SOAP 
header for the purpose.  Admittedly, this is not using the hook that was 
available to the XSL folks at the time they wrote their spec and which is 
therefore deployed in some existing software, but I'd claim it's 
architecturally much more robust.   Agreed:  that doesn't mean that PI's 
have no value, or that there aren't realistic scenarios in which the 
PI-choses-stylesheet approach will have value for compatibility with the 
XSL rec. 

(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.)

Bottom line:  if the Protocols WG needs to go back to last call for other 
reasons, I'm just fine with changing the PI rules at the same time.  I'd 
rather not go back to last call just over that.  Either way, I remain 
unconvinced that allowing a SOAP message to carry it's own 
presentation-styling information, outside the controls of SOAP mechanisms 
like mustUnderstand, is the compelling use-case for the PI.  If we want to 
come closer to allowing arbitrary XML in a SOAP body, that seems a better 
rationale for PI's.

BTW:  I think it was Elliotte who asked about unqualified element names in 
SOAP content:  the elements that are the roots of header entries, and the 
immediate children of <body> must be qualified, as they (typically) 
identify the processing to be performed;  other content need not be 
qualified, so namespace defaults must be handled with some care.

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







"Asir S Vedamuthu" <asirv@webmethods.com>
Sent by: xml-dist-app-request@w3.org
08/28/2002 01:16 PM
Please respond to asirv

 
        To:     "Martin Gudgin" <mgudgin@microsoft.com>, "Elliotte Rusty Harold" 
<elharo@metalab.unc.edu>, <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: Problem with resolution of Issue 221



> I agree entirely with Elliotte. Saying nothing about 
> PIs WRT SOAP processing makes life MUCH simpler. 
> Saying anything about them complicates things.

+1, I agree that it makes life MUCH simpler.

Asir

-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Martin Gudgin
Sent: Wednesday, August 28, 2002 12:59 PM
To: Elliotte Rusty Harold; xml-dist-app@w3.org
Subject: RE: Problem with resolution of Issue 221



[inline]

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu] 
> Sent: 28 August 2002 07:25
> To: xml-dist-app@w3.org
> Subject: RE: Problem with resolution of Issue 221
> 
> 
> 
> At 5:56 PM -0400 8/27/02, noah_mendelsohn@us.ibm.com wrote:
> 
> 
> >* PIs don't fit with SOAP encoding, because they have no natural
> >   representation in the graph model.  Therefore, we would be
> >   disallowing them in the envelope and in encoded content, but
> >   allowing them in unencoded content.
> 
> I don't understand this point, perhaps because I'm not a SOAP expert. 
> What's wrong with the proposed solution of simply saying SOAP defines 
> no processing of PIs?  By design, they are easy to ignore if you 
> don't want them. Why not allow them everywhere and just ignore them? 
> Why a dichotomy between the envelope and in encoded content and 
> unencoded content?

+1

> 
> >* Although Infoset oriented APIs such as SAX and DOM tend to reflect
> >   PIs quite naturally, more business oriented APIs get complicated
> >   when you introduce PIs.  Let's say I have a Java interface or C
> >   structure representing a purchase order body: do I really have to
> >   figure out what to do with a PI that shows up between the <state>
> >   and <zipcode> elements of a shipping address?
> 
> Again, I suspect most such APIs implicitly ignore these, and that's 
> what they're supposed to do. PIs are intended only for the processes 
> that are addressed by their targets, not for every process that reads 
> the document. There's a reason they're not elements. So, no, you 
> don't have to figure out what to do with a PI that shows up between 
> the <state>  and <zipcode> elements of a shipping address. You simply 
> ignore it.

+1

<SNIP/>
> 
> >* Finally, if the rationale is to allow arbitrary user XML in the
> >   body, but then it's somewhere between difficult and impossible
> >   anyway.
> 
> Difficult, yes but not impossible. The real problem here is the 
> DOCTPYE declaration. In practice, this can be solved by copying only 
> the root element of a document into a new document rather than the 
> entire document itself. (By copying, I mean API level copying as via 
> SAX or DOM or some such, not cut and paste).

I agree that this problem is tractable. Also, refering back to Noah's
comment, I'm not sure the rationale IS to allow arbitrary user XML in
the body.

> 
> >  Anything resembling an ID attribute has to be handled very
> >   carefully to avoid potential conflicts with IDs elsewhere in the
> >   envelope;
> 
> Yes, if you care about IDs. Many applications don't.
> 
> >  namespace declarations and particularly use of default
> >   namespaces can be tricky;
> 
> Yes, but only if you allow non-namespaced elements. If I recall 
> correctly, SOAP doesn't, or at least it didn't use to. Has this 
> changed in SOAP 1.2?

SOAP 1.1 allows unqualified elements as children of soap:Body. Children
of soap:Header MUST be qualified.

SOAP 1.2 states that children of soap:Body and soap:Header MUST be
namespace qualified.

Of course, other descendants of soap:Body/soap:Header could be
unqualified in both versions of the spec.

<SNIP/>
> 
> I think removing the capability of carrying PI's increases the 
> complexity of all these things. Consider conformance testing, for 
> example. It must now test that implementations don't allow PIs. 
> Without this requirement, no test is necessary.  PIs are simply not 
> part of SOAP processing, and thus there's no need to test for them. 
> Other, non-SOAP processes may use them, but that's neither here nor 
> there for SOAP testing.

I agree entirely with Elliotte. Saying nothing about PIs WRT SOAP
processing makes life MUCH simpler. Saying anything about them
complicates things.

Gudge

Received on Tuesday, 3 September 2002 11:04:08 UTC