- From: <noah_mendelsohn@us.ibm.com>
- Date: Thu, 16 Jan 2003 16:34:43 -0500
- To: Norman Walsh <Norman.Walsh@sun.com>
- Cc: www-tag@w3.org
Norm Walsh writes regarding PI's inSOAP: >> It is. But they are not explicitly forbidden, only very strongly deprecated. Actually, I disagree with that. The Candidate Rec says: [1] "SOAP provides a distributed processing model that assumes a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries." and then as has been previously quoted at [2]: "SOAP messages sent by initial SOAP senders MUST NOT contain processing instruction information items. SOAP intermediaries MUST NOT insert processing instruction information items in SOAP messages they relay. SOAP receivers receiving a SOAP message containing a processing instruction information item SHOULD generate a SOAP fault with the Value of Code set to "env:Sender". However, in the case where performance considerations make it impractical for an intermediary to detect processing instruction information items in a message to be relayed, the intermediary MAY leave such processing instruction information items unchanged in the relayed message." This is followed by an Infoset-level description of a SOAP message, and that description does not allow for PIs. Put together these say: "SOAP message Infosets do not contain PIs. All SOAP messages originate at an original sender, which MUST NOT put processing instructions in the message. All modifications to messages occur at intermediaries, which MUST NOT put processing instructions in the message." End of story. PIs are never legal in SOAP messages. They're disallowed by the format description (infoset), and they are specifically disallowed at the only places that SOAP messages can originate or be modified. The last part of the quote may be paraphrased as: "A receiver may find that it receives an erroneous message containing a PI. Receivers SHOULD report such errors if at all practical, but we recognize that such error detection may not in all cases be the best tradeoff. Accordingly, when absolutely necessary the erroneous message MAY be propagated down the line." I don't think it's quite fair to characterize this as saying they are not forbidden but only deprecated. Also: this is obviously controversial, but I don't see where it says in the XML recommendation that every application of XML must use every feature. Surely there are applications that use only elements, and will fault at the application level if confronted with an attribute. SOAP is such an application. It makes use of some attributes, but not of PIs. SOAP applications MUST NOT put PIs in messages, just as certain applications MUST NOT put attributes in their XML. SOAP is an application of XML, not a redefinition of it. I think the major practical implication is that SOAP messages are somewhat limited in their ability to carry arbitrary XML documents fragments as Body or Header data. XML is sufficiently broken in its ability to nest such arbitrary XML (conflicting entity definitions and inability to send nested DOCTYPE, for example) that we never could have achieved general container support in any case. As it happens, the semantics of a PI in a SOAP body would be very questionable. Does it apply only to the body, or to the SOAP message as a whole? PI's aren't well scoped to the XML tree...they just sort of float in the document. SOAP processing is tied very deeply to the tree structure of XML. Accordingly, it is somewhat difficult to provide stable semantics for PIs floating around in SOAP messages. That was among the reasons that I was one of those who endorsed the current design. As I say: we're an application of XML, and PIs did not meet our needs. Thank you. [1] http://www.w3.org/TR/2002/CR-soap12-part1-20021219/#msgexchngmdl [2] http://www.w3.org/TR/2002/CR-soap12-part1-20021219/#soapenv ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Thursday, 16 January 2003 16:35:51 UTC