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

Re: proposal: minor syntax improvement for soap fault bindings

From: John Kemp <john.kemp@nokia.com>
Date: Sat, 08 May 2004 08:58:24 -0400
Message-ID: <409CD970.5030804@nokia.com>
To: ext <paul.downey@bt.com>
Cc: pyendluri@webmethods.com, www-ws-desc@w3.org

Paul,

ext wrote:

<snipped/>

> so the subcodes still belong to the code and the order of
>the subcodes (if that's important) is preserved.
>  
>
So, this is my point - it's the difference between "ordering", and 
"belonging to" - in a flat list - (a, b, c), one does not know 
implicitly that item b belongs to item a, and item c to item b. One only 
knows that they may be followed in order from a to c. Of course they 
could be followed from c to a too. And that's why you need some extra 
definitional semantics to allow the processor of such a list to know how 
they should interpret the ordering of the list. So, to my mind it is not 
apparent at all that b is a "sub-code" of a, or c a "sub-code" of b.

If, however, you embed those sub-codes, one within the other, I think 
that it is possible to better model that "belonging to" relationship. C 
is an element belonging to b, and b is an element belonging to a in the 
following:

<a>
  <b>
    <c/>
  </b>
</a>

> if this doesn't answer your concerns, maybe you could enumerate 
>the 'implicit semantics enforced by schema' and i'll have a rethink?
> 
>  
>
See above. However, I guess there are two points:

1) Do we *want* the ability to model sub-codes as codes belonging to 
codes (rather than just a list of status codes)? If so, I think 
maintaining the tree of codes (roughly as in Sanjiva's original 
proposal, and modelled above) is a good idea - the relationship is 
displayed in the instance itself, and enforced by schema.
2) I don't see how having a tree of codes impacts your ability to send a 
trancated instance that still has the capability to do what you want (it 
would perhaps even be possible for the "value" attribute to still be a 
list of Qnames, with semantics defined in the specification text)

- JohnK

>Paul
>
>	-----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
>	
>	
>
>	Hi,
>	
>	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"/>
>	    </wsoap:code>
>	  </wsoap:code>
>	</fault>
>	
>	But one could always just say:
>	
>	<fault ref="some-ns:RequestID">
>	  <wsoap:code value="some-ns:DatabaseServerTimeoutFailure"/>
>	</fault>
>	
>	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).
>	
>	Cheers,
>	
>	- 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>*
>	>becomes:
>	>    <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.
>	>Paul
>	>
>	>
>	>       -----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 08:59:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT