Issue 221 (PI in soap documents)

A concrete example of the use of a PI.  An xml document
may specify the stylesheet to use for formatting via the
<?xml-stylesheet ...> PI.

http://www.w3.org/TR/xml-stylesheet/



Elliotte Rusty Harold wrote:

> 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 12:15:03 UTC