- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Thu, 31 Jan 2002 13:34:03 +0100
- To: Jacek Kopecky <jacek@systinet.com>
- CC: "Williams Stuart" <skw@hplb.hpl.hp.com>, xml-dist-app@w3.org
If your mechanism was part of the core spec, we would not need the outbound <faultNodeIDRequest> header, would we? We would simply have the inbound <faultNodeID>, right? As Stuart, I'd hate to use headers for such a simple mechanism; but I understand your concern... Jean-Jacques. Jacek Kopecky wrote: > [...] The extension could be something like the following: > > Non-fault messages contain a header > <ns:faultNodeIDRequest xmlns:ns="..." > env:role=".../next" env:mustUnderstand="true"? /> > The contract of this header would be such that the receiving > node, upon faulting (other than mustUnderstand, I think, but I'm > not sure about this point because of the ordering of > "understanding" a header and fulfilling its contract), would put > in the fault message a header > <ns:faultNodeID xmlns:ns="...">uri</ns:faultNodeID>
Received on Thursday, 31 January 2002 07:35:35 UTC