Re: ALTERNATIVE PROPOSAL: Short-cut syntax for in-out and in-only patterns

A couple of comments, and a third alternative proposal.

On Mon, 03 Nov 2003 10:46:32 +0100
Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr> wrote:
> 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"/>*

Comment 1: faults are not named in patterns.  This part of the proposal
therefore won't work.  Faults are associated with messages; the
tag-names of the faults then would replicate those of the messages. 
Also not good, since it creates ambiguity about what is a fault and what
is a message.  In short, minimum syntax for a fault must be something on
the order of:

<fault messageReference="xs:NCName" details="xs:QName" />
This assumes that the messageReference is named in the pattern, with a
simple name.  If, using Jean-Jacques proposal, we were to go for
per-message tag-names, then we might have @messageReference="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.

I agree.  I think that it is possible to achieve much of it without
introducing variable tag-names for messages, though, which is the
substance of my proposal, below.  More comments first.

> 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.

+1 to JJM's commment.

> > - 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.

Here I find myself in agreement with Sanjiva.  For the common case in
which there is a single message in a particular direction, I think
requiring that the user remember the name with which that message is
defined within the message is a potential burden.

>  >   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.

I disagree with both of these.

Here's a third outline
  <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> 

Proposed syntactic changes:
    - Make
interface/operation/(input|output|infault|outfault)/@messageReference
      optional
(this was one of Sanjiva's proposals)

Introduce the following rule:
    - When a pattern contains only one message in a given direction,
then the messageReference attribute is optional.  When a pattern
contains more than one message in a given direction, then the
messageReference attribute is required (to disambiguate which message is
defined by the element).

This is a simpler proposal, which reduces the burden where the real
redundancy is.  It also does not make the patterns defined by the
working group special cases with special privileges, which I believe to
be inappropriate.  It does not introduce a large number of new element
names into the content of <operation>.  It *does* allow shortcuts not
only for simple patterns defined by the WSD WG, but also by
developers/designers who provide additional simple patterns.
 
> > 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.

I think that this makes the parse code that must be developed to
determine pattern-in-use for an operation much more difficult.  I think
it also creates a learning burden for WSDL authors, who must remember
different rules for the "special patterns" than for the "generic
patterns", which I think likely to lead to invalid (impossible to
disambiguate) WSDL.  Replacing this with a single rule that looks more
algorithmic (well, it does to me, anyway) seems a better solution.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 3 November 2003 10:16:52 UTC