OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-tx] Issue 030 - Proposal 2 silence on WS-A faults



>>  
> In one dimension, I think you are right to logically group the Invalid 
> State and Invalid Parameters with the WS-A SOAP Binding predefined 
> faults: they report "bozo bugs" (non-conformant implementation errors 
> that ought to get eliminated in testing, like the malformation errors 
> that can occur at the WS-A level).
>
> In another dimension, as Max points out, they belong in WS-TX because 
> they are logic error faults at the WS-TX layer. I think that his 
> argument against layer violation is compelling. You could argue that 
> they are unnecessary faults, i.e. that they SHOULD or MAY be sent to 
> help debugging and testing, but I think they belong to WS-TX, and 
> should use its mechanisms.
>
On the one hand I agree, but on the other hand (and as pointed out 
yesterday in a separate email response to Max), this is an argument that 
spans more than just this TC: TX may not be the only group that believes 
wsa:FaultTo as being useful only at a certain "level" of the protocol 
stack (essentially WS-A related problems). It's also potentially just an 
implementation detail: there is no reason at all that wsa:FaultTo 
couldn't be used to direct TX specific faults to the right "layer" in 
the protocol stack.

Mark.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]