RE: Problem with resolution of Issue 221

Mike Champion asks:

>> So, someone help me understand this: It makes perfect
>> sense to disallow PIs in the SOAP markup (oops, sorry,
>> Infoset contribution) and processing model, and maybe
>> header elements because they are so closely involved in
>> the SOAP processing model, but why make them illegal in
>> bodies?

Well, I think there are pros and cons either way.  I personally could have 
lived with a decision to allow PIs in bodies and in header entries, but 
also think the decision of the workgroup is a reasonable one.  I cannot 
speak as to the workgroup's actual reasons, but here are some of the pros 
and cons as I see them:

PROS
----

* Comes closer to allowing arbitrary XML in SOAP user data.

* Supported by many off-the-shelf parsers and APIs such as SAX and DOM.

* XML allows 'em, so don't change it.

CONS
----

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

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

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

* Finally, if the rationale is to allow arbitrary user XML in the
  body, but then it's somewhere between difficult and impossible
  anyway.  Anything resembling an ID attribute has to be handled very
  carefully to avoid potential conflicts with IDs elsewhere in the
  envelope; namespace declarations and particularly use of default
  namespaces can be tricky; and as noted above, user-defined entities
  cannot be used.  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 (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.)


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'm not trying to claim that these "cons" are compelling; I agree the
decision could have gone the other way.  I do think they show that the
decision of the WG is at least plausible.

Having said that, I would also like to point out that the workgroup
has reached the point that most successful software projects reach,
where having a stable design and shipping a specification begins to
grow in importance relative to making every design decision perfectly.
Even if I personally felt that allowing PIs were a slightly better
decision, I think we are passed the point where I would argue for
reopening it.  The W3C process would require that we had weeks or
perhaps months to our release cycle to go back through the reviews
that would be necessary for additional function of this sort (whether
the process is reasonable in this respect is a different question;
that's the way the process is at the moment.)  So, for all those
reasons, I recommend that we live with the decision of the workgroup.
Thank you.

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

Received on Tuesday, 27 August 2002 17:57:19 UTC