W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2004

RE: proposal: minor syntax improvement for soap fault bindings

From: <paul.downey@bt.com>
Date: Sat, 8 May 2004 12:18:53 +0100
Message-ID: <2B7789AAED12954AAD214AEAC13ACCEF0FFF2207@i2km02-ukbr.domain1.systemhost.net>
To: <john.kemp@nokia.com>
Cc: <pyendluri@webmethods.com>, <www-ws-desc@w3.org>
the purpose of describing fault codes/subcodes in the SOAP 
binding is to direct them at an abstract fault which is now a 
first class citizen of the interface.
we already have lists of qnames elsewhere in WSDL 2.0,
so there is precident for this micro-parsing.
schema can constrain a list of qnames as follows:
    <xs:attribute name='subcodes' use='optional' >
        <xs:list itemType='xs:QName' />
so the subcodes still belong to the code and the order of
the subcodes (if that's important) is preserved.
my concern is that the ability to document individual SOAP subcodes 
is lost, but i think that's a small loss for the increased simplicity.
if this doesn't answer your concerns, maybe you could enumerate 
the 'implicit semantics enforced by schema' and i'll have a rethink?

	-----Original Message----- 
	From: John Kemp [mailto:john.kemp@nokia.com] 
	Sent: Fri 07/05/2004 15:45 
	To: Downey,PS,Paul,XSJ67A C 
	Cc: pyendluri@webmethods.com; www-ws-desc@w3.org 
	Subject: Re: proposal: minor syntax improvement for soap fault bindings

	I would just note that with all these proposals, we are losing some
	implicit semantics enforced by schema, and I'm not quite sure why we
	need to do that.
	As I understand it (and please correct me if I'm wrong), the main reason
	for flattening the status code hierarchy would be to allow minimal fault
	instances to be created. However, even with a status code hierarchy
	possible in *schema*, there would be no requirement for any application
	to use the whole hierarchy in any individual instance, and I think we
	would lose something by flattening that structure, unless we defined the
	semantics of the flattened list of sub-codes in specification text.
	So, I guess I'm saying that I prefer having the *ability* to use nested
	status codes, where the structure is visible in the document instance -
	I think some applications may find it useful to have the ability to be
	wordy in their status reporting, even if most don't. Unless there is
	some other good, but as yet unstated reason, I would argue that we
	should not flatten the structure in schema purely for the purpose of
	creating small instances, which is to say I'm pretty much in agreement
	with Sanjiva's original proposal.
	An example:
	<fault ref="some-ns:RequestID">
	  <wsoap:code value="some-ns:Failure" description="Request Failed"/>
	    <wsoap:code value="some-ns:Timeout" description="Database Server
	Connection Timeout">
	      <wsoap:code value="some-ns:ConnectionFailure" description="Could
	Not Connect To Database"/>
	But one could always just say:
	<fault ref="some-ns:RequestID">
	  <wsoap:code value="some-ns:DatabaseServerTimeoutFailure"/>
	If one wished to be brief.
	However, if people also want to be able to stick a list of Qnames in the
	first status code element, we could perhaps allow that too, but we would
	need to either say explicitly that there is no implication of structure
	in the Qname list, or define some associated structure semantics (ie.
	that the list was in fact a structured hierarchy of codes).
	- JohnK
	Paul wrote:
	>thanks! i further suggest applying Jacek's rule of never
	>having an element or attribute called 'value' and hoist the
	>code and subcode attributes into fault meaning:
	>    <fault ref="xs:QName" >
	>      <documentation />?
	>      <wsoap:code>
	>        <wsoap:value>xs:QName</wsoap:value>
	>        <wsoap:subcode>
	>          <wsoap:value>xs:QName</wsoap:value>
	>          <wsoap:subcode>...</wsoap:subcode>
	>        </wsoap:subcode>?
	>      </wsoap:code>
	>    </fault>*
	>    <fault ref="xs:QName"
	>         wsoap:code="xs:QName"
	>         wsoap:subcodes="list of xs:QName" />
	>      <documentation />?
	>    </fault>*
	>downside is we can no longer document individual fault codes,
	>but that seems to be no great loss to me since this is all
	>about grouping and routing codes to a meaningful interface fault.
	>       -----Original Message-----
	>       From: www-ws-desc-request@w3.org on behalf of Prasad Yendluri
	>       Sent: Thu 06/05/2004 19:05
	>       To: www-ws-desc@w3.org
	>       Cc:
	>       Subject: Re: proposal: minor syntax improvement for soap fault bindings
	>       I guess we kinda settled on the original proposal from Sanjiva on the call today but, I like this improvement. It satisfies the intent of Roberto's suggestion while keeping the separation between code and sub-codes.
	>       Prasad
	>       -------- Original Message --------
	>Subject:       RE: proposal: minor syntax improvement for soap fault bindings 
	>Resent-Date:   Thu, 6 May 2004 12:39:37 -0400 (EDT)   
	>Resent-From:   www-ws-desc@w3.org     
	>Date:  Thu, 6 May 2004 17:39:07 +0100 
	>From:  <paul.downey@bt.com> <mailto:paul.downey@bt.com>       
	>To:    <Roberto.Chinnici@Sun.COM> <mailto:Roberto.Chinnici@Sun.COM> , <sanjiva@watson.ibm.com> <mailto:sanjiva@watson.ibm.com>        
	>CC:    <www-ws-desc@w3.org> <mailto:www-ws-desc@w3.org>       
	>       as suggested, verbally on the telcon:
	>          <wsoap:code value="xs:QName" subcodes="list of xs:QName" />
	>       solves the problem of the first value having a different meaning
	>       to the rest of the list.
	>       Paul
	>       -----Original Message-----
	>       From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
	>       Behalf Of Roberto Chinnici
	>       Sent: 04 May 2004 01:05
	>       To: Sanjiva Weerawarana
	>       Cc: www-ws-desc@w3.org
	>       Subject: Re: proposal: minor syntax improvement for soap fault bindings
	>       How about a further improvement? Instead of
	>              <wsoap:code value="xs:QName">
	>                <wsoap:subcode value="xs:QName">
	>                  <wsoap:subcode>...</wsoap:subcode>
	>                </wsoap:subcode>?
	>              </wsoap:code>
	>       we do:
	>              <wsoap:code value="list of xs:QName">
	>              </wsoap:code>
	>       I.e. the value of @code is a list of QNames, the first one being
	>       the code and the other ones its subcodes. And of course we cshould
	>       constrain the list to have length > 0.
	>       Roberto
	>       Sanjiva Weerawarana wrote:
	>       > I suggest we move wsoap:code/wsoap:value to an attribute:
	>       >
	>       > That is, instead of:
	>       >
	>       >       <wsoap:code>
	>       >         <wsoap:value>xs:QName</wsoap:value>
	>       >         <wsoap:subcode>
	>       >           <wsoap:value>xs:QName</wsoap:value>
	>       >           <wsoap:subcode>...</wsoap:subcode>
	>       >         </wsoap:subcode>?
	>       >       </wsoap:code>
	>       >
	>       > we do:
	>       >
	>       >       <wsoap:code value="xs:QName">
	>       >         <wsoap:subcode value="xs:QName">
	>       >           <wsoap:subcode>...</wsoap:subcode>
	>       >         </wsoap:subcode>?
	>       >       </wsoap:code>
	>       >
	>       > This makes the syntax more consistent with the rest of the
	>       > SOAP binding which is rather attribute-heavy.
	>       >
	>       > Sanjiva.

Received on Saturday, 8 May 2004 07:19:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:40 UTC