I would like to make the following alternative proposal. I believe it
addresses Sanjiva's main issues.
The syntax for an in-out operation would be as follows:
<interface name="xs:NCName"
extends="list of xs:QName"?
styleDefault="xs:anyURI"?>
<operation name="xs:NCName"
pattern=".../in-out"
style="xs:anyURI"?>
<A body="xs:QName"?
headers="list of xs:QName"?/>
<B body="xs:QName"?
headers="list of xs:QName"?/>?
<F details="xs:QName"/>*
</operation>
</interface>
Other patterns would be treated in a similar way.
Note: we might wish to define A, B, etc. in a different namespace, for
example "wsdlp".
Note: this is not a fully-fledged proposal, which people are unlikely to
have time to read before the f2f. I am happy to draft an enhanced
proposal if the WG wishes so.
Comments on Sanjiva's proposal below. Basically, I am concerned
Sanjiva's proposed syntax trades-off clarity for heuristics.
Jean-Jacques.
Sanjiva Weerawarana wrote:
> This is a follow-up email to the proposal I made at the last F2F
> to introduce some defaulting rules to make the syntax for
> in-out and in-only patterned operations more syntactically
> pleasing.
>
> Status quo syntax for operations:
> --------------------------------
>
> <interface name="xs:NCName"
> extends="list of xs:QName"?
> styleDefault="xs:anyURI"?>
> <operation name="xs:NCName"
> pattern="xs:anyURI"
> style="xs:anyURI"?>
> <input messageReference="xs:NCName"
> body="xs:QName"?
> headers="list of xs:QName"?/>*
> <output messageReference="xs:NCName"
> body="xs:QName"?
> headers="list of xs:QName"?/>*
> <infault messageReference="xs:NCName" details="xs:QName"/>*
> <outfault messageReference="xs:NCName" details="xs:QName"/>*
> </operation>
> </interface>
>
>
> Problems with status quo:
> ------------------------
>
> - User has to remember pattern URIs, even for simple operations
Srictly speaking, the user has to remember only the pattern URI's tail,
i.e. in-only, in-out, out-only, etc; the rest
(http://www.w3.org/@@@@/@@/wsdl/) is WSDL's standard prefix. Remembering
the tail sounds simple enough to me.
> - User has to know contents of pattern spec to know proper values
> for @messageReference (typically 'A', 'B' etc. right now).
Perhaps. However, again, 'A', 'B', etc. look to me like names the user
is likely to be able to remember.
> The
> value for @messageReference is *not* user settable, while the
> other attributes are - which I believe to be counter-intuitive.
Yes. However I think we can address this in a different way (see
proposal above).
> - "input" and "output" are redundant as the pattern defines the
> direction of the message - thus the indicated message reference
> already has a set direction and the user cannot change it. Thus
> indicating both message reference and input vs. output is an
> an opportunity for errors
Agreed. I think we can address this in a different way as well (see
proposal above).
> - "infault" / "outfault" separation similarly redundant and error-prone
Ibid.
> To me, requiring users to remember pattern URIs for the everyday
> patterns is unacceptable. Furthermore, requiring *users* to know
> the content of the patterns spec for those patterns (so that they
> can assign proper values for @messageReference) is even worse. W.r.t.
> the redundancies- I'd like to eliminate as many redundancies as
> possible. Finally, the motivation for the proposal is to keep the
> simple case simple, yet not harm the complex case in any way.
>
> Proposal:
> --------
>
> I proposed that we introduce a set of very simple rules to enable
> one to derive the message exchange pattern URI and message reference
> names for operations using the in-only and in-out patterns.
>
> We observe that for the in-only MEP there is only one input message
> and no fault messages. Similarly, the in-out MEP has one input
> message, one output message and zero or more outfaults, all of
> which are related to the single output message.
>
> Proposed syntactic changes:
> - Make interface/operation/@pattern optional
> - Make interface/operation/(input|output)/@messageReference
> optional
>
> Now, introduce the following rules to compute these when they are
> absent:
> - There must be precisely one <input> element inside the
> operation- if not its an error as the user should have
> specified the MEP
> - There must be precisely zero or one <output> element inside the
> operation- if not its an error as the user should have
> specified the MEP
> - There must not be any <infault> elements inside the operation-
> if not its an error as the user should have specified the MEP
> - If there is an <output> element, then @pattern="in-out" else
> @pattern="in-only"
> - Set value of the messageReference attribute for the <input>
> element to 'A' (or if indicated it better be 'A')
> - If there is an <output> element, set the value of its
> messageReference attribute to 'B' (or if indicated it better be 'B')
> - If pattern is "in-only", then there must not be any <outfault>
> elements or its an error
> - If there are any <outfault> elements, set the value of its
> messageReference attribute to 'B' (or if indicated it better be 'B')
>
> The resulting syntax for in-only and in-out operations is:
>
> <interface name="xs:NCName"
> extends="list of xs:QName"?
> styleDefault="xs:anyURI"?>
> <operation name="xs:NCName"
> style="xs:anyURI"?>
> <input body="xs:QName"?
> headers="list of xs:QName"?/>
> <output body="xs:QName"?
> headers="list of xs:QName"?/>?
> <outfault details="xs:QName"/>*
> </operation>
> </interface>
>
> A similar simplification is possible for <binding>s for in-only
> and in-out patterned operations (basically make the @messageReference
> attribute optional).
>
> Conclusion:
> ----------
>
> We believe that these proposed shortcuts are critical to support
> what we believe to be easily the 80-20 usecase of WSDL; WSDLs
> that have only in-only or in-out operations. The proposed
> changes are minimal (make two attributes optional) and the
> proposed rules are very simple to implement even on small devices
> (or large mainframes). We believe that the resulting user-level
> simplification clearly justifies the adoption of this proposal.
>
> Sanjiva.
>
>