- 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