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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: RE: [ws-caf] Revised MustUnderstand Proposal


Greg, for clarity can you re-phrase the issue and the proposal as it would now 
stand, given the input. I'm still confused as to what is issue and what is 
proposal.

Mark.

>===== Original Message From Greg Pavlik <greg.pavlik@oracle.com> =====
>Peter,
>
>Does this satisfy your concern? Does anyone else have comments on this?
>I'd like to close out some of these basic issues so we can lock down
>context/coordination and move on to the transaction space in the next
>few weeks.
>
>Greg
>
>Kevin Conner wrote:
>
>> Furniss, Peter wrote:
>>
>>> SOAP 1.2 says "A SOAP header block is said to be understood by a SOAP
>>> node if the software at that SOAP node has been written to fully conform
>>> to and implement the semantics specified for the XML expanded name of
>>> the outer-most element information item of that header block".
>>
>>
>> My understanding of this statement is that a SOAP node must have some
>> mechanism of processing the header identified by the outer element and
>> whether this processing is successful or not is another issue.
>> Identification and handling of extensions is, to my mind, part of the
>> processing stage.
>>
>> If the header arrives without the mustUnderstand attribute, and the
>> SOAP node decides that it should handle it in any case, then I would
>> hope that errors in processing would be handled in the same way.
>>
>>> Does an soap header-specifying spec (like ws-caf) have then to define
>>> its own "header not fully understood" fault, or can it interpret "fully
>>> conform to and implement" as including the effects of values which are
>>> not recognised, but known (by their placement or type) to be critical to
>>> the full implementation of the senders intent.  It would seem mildly
>>> perverse of SOAP to say we must define our own fault merely because they
>>> have been selfish with theirs :-)
>>
>>
>> I would certainly like to see a context specific fault representing an
>> unknown addressing specification. :-)
>>
>>    Kev
>>




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