- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 6 Sep 2002 12:29:58 -0400
- To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
- Cc: Marc Hadley <marc.hadley@sun.com>, Martin Gudgin <mgudgin@microsoft.com>, W3C Archive <www-archive@w3.org>
Jean-Jacques Moreau writes: >> I still find it bizarre, though, that >> an intermediary must not insert a PI but >> may relay one. This seems a little >> inconsistent to me. Why? I think the notion is that adding content is something that you do very explicitly, so doing it wrong is just an error and is never excused. The reason for allowing wiggle room at all is the thinking that relaying someone else's content is something that you sometimes want to do in a sort of black-box highly optimized manner. Think of a hardware or microcode implementation that makes sure the role attributes don't match the intermediary, then just cut-through streams the header until the end-tag is matched. (Perhaps an over-simple example, but I think the spirit is right.) There's no reason in the world that such an intermediary should be granted license to _insert_ erroneous content. So, I think the approach taken at the F2F is at least plausible, if not necessarily ideal. <yetAnotherProposal> SOAP messages MUST not contain XML Processing instructions. Accordingly, initial SOAP senders MUST NOT include processing instructions in a SOAP message, and SOAP intermediaries MUST NOT insert into a SOAP message new headers containing processing instructions. An ultimate SOAP recevier that receives a message containing one or more Processing Instructions MUST fault with a SENDER fault. A SOAP intermediary receiving a message containing one or more Processing Instructions SHOULD fault with a sender fault, but in situations where performance considerations make such fault detection impractical at the intermediary, the intermediary MAY instead retain the received Processing Instructions in the relayed message. If the intermediary chooses not to fault, it MUST retain all the Processing Instructions in the relayed message (the intention being that a downstream intermediary or ultimate receiver will eventually detect the error and fault). </yetAnotherProposal> The last sentence is an innovation, but I think it makes sense. Does the above help? ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Friday, 6 September 2002 12:31:30 UTC