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 Wednesday, 28 August 2002 12:59:43 UTC