- From: John Kemp <john.kemp@nokia.com>
- Date: Sat, 08 May 2004 08:58:24 -0400
- 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 UTC