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 02:49:06 UTC