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?

>* 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.

>* Because SOAP is a simplified subset of XML (no DTDs, therefore no
>   user defined general entities, etc.), some SOAP implementations can
>   use highly tuned special-purpose XML parsers.  Implementing PIs is
>   just one more complication for such parsers, may slow them down a
>   bit, have to reject them outside user-data anyway, etc.

As Tim Bray has noted elsewhere, special purpose XML parsers are not 
in common use. There are many small, fast, open source XML parsers 
that are can be used by SOAP processors and are likely to be much 
faster than any home-cooked solution.

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

>  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?

>  and as noted above, user-defined entities
>   cannot be used.

Yes, but this is only an issue at the copy and paste, hand authoring 
level. APIs should and often do just resolve all this.

>Given that SOAP is not designed to carry arbitrary
>   XML payloads anyway, one can argue that adding in PIs just adds a
>   bit of complication without really solving much for users

Au contraire, I'd argue that every special case SOAP adds increases 
the complexity for users. Satying that SOAP messages are XML but they 
can't include certain features of XML like PIs, makes it more 
complex, not less. Taking PIs out of XML would have made XML less 
complex (and less powerful) but SOAP is the wrong layer to remove 
features. Every change SOAP makes to XML, increases complexity.

>  (BTW: I
>   think it is one of the two or three greatest failures of XML intself
>   that it is a hierarchical model that cannot cleanly contain
>   instances of itself; most of the limitations in carrying XML in SOAP
>   traced to this limitation of XML itself.)

Yes, but we can't really fix that.

>In short, even a simple capability of carrying PI's introduces
>some complexity into the specifications, into applications and
>APIs, and into conformance testing.
>

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

+-----------------------+------------------------+-------------------+
| 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 Wednesday, 28 August 2002 10:33:25 UTC