W3C home > Mailing lists > Public > public-ws-addressing@w3.org > June 2005

Re: content of fault detail

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 13 Jun 2005 10:52:59 -0700
Message-ID: <42ADC7FB.5030102@oracle.com>
To: Jacek Kopecky <jacek.kopecky@deri.org>
CC: Mark Nottingham <mark.nottingham@bea.com>, public-ws-addressing@w3.org

 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.


-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
>>
> 
> 
> 
Received on Monday, 13 June 2005 17:53:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:05 GMT