W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

RE: Who Faulted (was RE: Proposed rewrite of Part 1, section 2 (l ong) )

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 31 Jan 2002 10:34:42 -0000
Message-ID: <5E13A1874524D411A876006008CD059F19291F@0-mail-1.hpl.hp.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT