Re: content of fault detail

On Jun 13, 2005, at 1:52 PM, Anish Karmarkar wrote:
>
> From an implementation POV, it is quite convenient to deal with  
> SOAP 1.1 and SOAP 1.2 errors/faults in same/similar way. Given the  
> stmt pointed out by Jacek in SOAP 1.2 part 1 (that the Detail EII  
> is intended for error info related to SOAP Body), I would like to  
> suggest that whatever mechanism we adopt to resolve issue LC56 also  
> be extended to SOAP 1.2. This would make:
> 1) error processing for SOAP 1.1 and 1.2 very similar (would use  
> the same headers for carrying fault details).
> 2) resolve LC 72
> 3) keep the spirit of SOAP 1.2 Detail EII.
>
IIRC, the quoted text from SOAP 1.2 is the subject of an errata[1]  
that strikes the 'related to the SOAP Body'. Given this I don't think  
we should adopt the same approach for the two protocols.

Marc.

[1] http://www.w3.org/mid/5A220E02-63EE-11D9-80B7-000A95BC8D92@Sun.COM

>
> -Anish
> --
>
> Jacek Kopecky wrote:
>
>> Mark, this is not an issue that I personally care about much, it's  
>> just that
>> WS-Addressing seems to violate this statement in the SOAP spec:
>> "The Detail element information item is intended for carrying
>> application specific error information related to the SOAP Body." [1]
>> Even though this has been uncovered after the end of the LC  
>> period, it
>> should probably be fixed before CR, and the scope of LC56 seems  
>> limited
>> to SOAP 1.1, but this should be correct in both supported SOAP  
>> versions.
>> Best regards,
>> Jacek
>> [1] http://www.w3.org/TR/soap12-part1/#faultdetailelement
>> On Sun, 2005-06-12 at 13:06 +0200, Mark Nottingham wrote:
>>
>>> Jacek,
>>>
>>> As you may know, our comments period is over. However, I'd note  
>>> that  the issue you raise seems to be similar to that in lc56  
>>> [1], and as  such is likely to be covered when we discuss that  
>>> issue.
>>>
>>> Regards,
>>>
>>>
>>> 1. http://www.w3.org/2002/ws/addr/lc-issues/#lc56
>>>
>>> On Jun 3, 2005, at 6:30 PM, Jacek Kopecky wrote:
>>>
>>>
>>>
>>>> Hi again,
>>>>
>>>> as a followup to the original issue quoted below, after reading  
>>>> Anish's
>>>> proposal [1], I noted a further issue.
>>>>
>>>> The problem is, SOAP (at least 1.2) says that header-related fault
>>>> details must be headers, not in fault detail. WS-Addressing  
>>>> faults are
>>>> arguably header-related, therefore the details should probably be
>>>> formulated as headers. See SOAP 1.2's NotUnderstood header [2].
>>>>
>>>> Hope it helps,
>>>>
>>>> Jacek
>>>>
>>>> [1]  http://lists.w3.org/Archives/Public/public-ws-addressing/ 
>>>> 2005Jun/ 0003.html
>>>> [2] http://www.w3.org/TR/soap12-part1/#soapnotunderstood
>>>>
>>>>
>>>> On Tue, 2005-05-03 at 17:26 +0200, Jacek Kopecky wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> as an LC comment for WS-Addressing, I'd like to note that in  
>>>>> SOAP 1.2,
>>>>> fault detail (the element S:Detail) can only contain element  
>>>>> children,
>>>>> which is apparently violated by sections 5.2 and 5.4 of WS- 
>>>>> Addressing
>>>>> SOAP binding.
>>>>>
>>>>> The sections say, respectively:
>>>>>
>>>>> 5.2: [Detail] [Missing Property QName]
>>>>> 5.4: [Detail] [action]
>>>>>
>>>>> The values (QName, anyURI) must be somehow enclosed in elements  
>>>>> (or
>>>>> represented as elements, which is doable for the QName) to be   
>>>>> compatible
>>>>> with SOAP 1.2 fault detail.
>>>>>
>>>>> Best regards,
>>>>>
>>>>>                   Jacek Kopecky
>>>>>
>>>>>                   Ph.D. student researcher
>>>>>                   Digital Enterprise Research Institute
>>>>>                   University of Innsbruck
>>>>>                   http://www.deri.org/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Mark Nottingham   Principal Technologist
>>> Office of the CTO   BEA Systems
>>>
>>> -------------------------------------------------------------------- 
>>> ------------
>>>
>>> Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a  
>>> unique online event, giving you the first look at a new category  
>>> of enterprise software built specifically for Service-Oriented  
>>> Architecture (SOA).
>>>
>>> Register Now.  It's Free!
>>>
>>> http://www.bea.com/events/june15
>>>
>>>
>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.