RE: proposal: minor syntax improvement for soap fault bindings

John
 
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:simpleType>
        <xs:list itemType='xs:QName' />
      </xs:simpleType>
    </xs:attribute>
 
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?
 
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 07:19:38 UTC