- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Thu, 31 Jan 2002 10:34:42 -0000
- To: "'Jacek Kopecky'" <jacek@systinet.com>
- Cc: xml-dist-app@w3.org
Hi Jacek, I think I'd be inclined to add an optional faultNode element to the content model of SOAP Faults. That would be simple and consistent with the treatment of faultActor. I think defining it as an extension makes such a simple thing seem awfully complicated (but then I should talk ;-)). Regards Stuart -- > -----Original Message----- > From: Jacek Kopecky [mailto:jacek@systinet.com] > Sent: 31 January 2002 07:49 > To: Williams, Stuart > Cc: xml-dist-app@w3.org > Subject: RE: Who Faulted (was RE: Proposed rewrite of Part 1, > section 2 > (l ong) ) > > > Stuart, > just a clarification: > An important rule about the fault detail is that it MUST be > empty if the fault was in processing a header - it is a header > again that MAY carry the details about the fault (section 4.4.4 > in the editors' copy). > I don't think we would want two differing mechanisms for > identifying the failing node for intermediaries and for the > ultimate destination, therefore I suggested the extension using > headers. > 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> > > We seem to agree, I think. 8-) > > Jacek Kopecky > > Senior Architect, Systinet (formerly Idoox) > http://www.systinet.com/ > > > > On Wed, 30 Jan 2002, Williams, Stuart wrote: > > > Hi Jacek, > > > > Hmmm.... well if is worth doing at all I actually think > its part of the > > fault. If fault detail gives us enough extensibility to do > this kind of > > thing I'd do it there and perhaps try to encourage some > kind of convention. > > > > Hadn't even thought of headers with faults... and it does > kind of raise the > > question of where would those come from? Do they get sort > of cloned from the > > message that faulted? Does the spec. that describes a SOAP > extension or the > > semantics of the body describe what headers (if any) with > faults that it > > generates? Hmmmm.... I really need to reaquaint myself > with the what the > > spec. says about the structure of fault messages. > > > > So... I'd be 'satisfied' if you can essentially include > the informations in > > fault detail already, which I think you alluded to earlier > as a possibility. > > I'd be even more satisfied if some 'convention' evolved > such that in > > circumstances where it were deemed to be a useful piece of > information to > > include in fault, it were included in a fault in a > consistent fashion. > > > > Do we have to write such a convention into SOAP 1.2? I > don't think so... > > > > Stuart > > -- > > > -----Original Message----- > > > From: Jacek Kopecky [mailto:jacek@systinet.com] > > > Sent: 30 January 2002 22:37 > > > To: Williams, Stuart > > > Cc: xml-dist-app@w3.org > > > Subject: RE: Who Faulted (was RE: Proposed rewrite of Part 1, > > > section 2 > > > (l ong) ) > > > > > > > > > Stuart, > > > I think I can see where you are headed. > > > I can also envision an extension which would keep a header in > > > all messages, targeted at ../next, whose semantics would be that > > > "any generated fault message (resulting from processing of this > > > original message) will contain a header with the faulting node's > > > identifier (what it means would be specified by this > extension)". > > > This extension can be wery simply added later by W3C or any > > > third party, just as our MU reporting extension, and it would > > > further prove the model. > > > What do you think? Would the possibility of such a solution (in > > > the future) satisfy you? (I don't like just leaving people "not > > > pushing", I like satisfying them.) > > > > > > Jacek Kopecky > > > > > > Senior Architect, Systinet (formerly Idoox) > > > http://www.systinet.com/ > > > > > > > > > > > > On Wed, 30 Jan 2002, Williams, Stuart wrote: > > > > > > > Hi Jacek, > > > > > > > > I'm not sure I agree. Independently we have the concepts > > > of roles (or > > > > actors) and nodes. Each can have identity and in a Web > > > world I'd identities > > > > to be expressed as URI's. At the SOAP level I don't think > > > node identity is > > > > "very dependent on the binding used" - a least not > > > syntactically from the > > > > pov of encoding an identifier for a node in a message - > > > its 'just another' > > > > URI. > > > > > > > > But... I'm not going to push that we go there. > > > > > > > > Good night, > > > > > > > > Stuart > > > > > > > > > -----Original Message----- > > > > > From: Jacek Kopecky [mailto:jacek@systinet.com] > > > > > Sent: 30 January 2002 22:11 > > > > > To: Williams, Stuart > > > > > Cc: xml-dist-app@w3.org > > > > > Subject: Re: Who Faulted (was RE: Proposed rewrite > of Part 1, > > > > > section 2 > > > > > (long) ) > > > > > > > > > > > > > > > Stuart, > > > > > exactly as you say, so far we have avoided identifying > > > nodes and > > > > > we were talking about roles only. I think adding > addressing, > > > > > which is very dependent on the binding used and on > other things, > > > > > to the core (next to faulting) would be a lot of > hairy work. I > > > > > suggest we don't go there. Or at least not for 1.2. > > > > > Good night, 8-) > > > > > > > > > > Jacek Kopecky > > > > > > > > > > Senior Architect, Systinet > (formerly Idoox) > > > > > http://www.systinet.com/ > > > > > > > > > > > > > > > > > > > > On Wed, 30 Jan 2002, Williams, Stuart wrote: > > > > > > > > > > > > > > > > > Hi Jacek, > > > > > > > > > > > > Sure... it wasn't a heavy suggestion, but any such > > > > > extension might benefit > > > > > > from a common mechanism to denote what node faulted, > > > > > rather than inventing > > > > > > its own means of dropping the information in the fault > > > > > detail. Doing it an > > > > > > common way also means that the information is accessible > > > > > to things that > > > > > > don't understand the extension. It may also be the case > > > > > that there is such a > > > > > > mechanism... I haven't looked at the faulting > parts of the > > > > > spec recently. > > > > > > > > > > > > Any not really pushing, was just wondering generally > > > > > whether it was more > > > > > > useful to know what node or what role faulted > and in some > > > > > cases you'd > > > > > > probably want one, the other or both (although > we have now > > > > > completely > > > > > > avoided identifying nodes (I think) by talking solely > > > about roles). > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Stuart > > > > > > > > > > > > > > > > > > > > >
Received on Thursday, 31 January 2002 05:34:21 UTC