Re: problem with pattern attribute definition?

Amy,
Makes total sense!
-Ram

On 2/16/07, Amelia A. Lewis <[email protected]> wrote:
>
> Ramkumar Menon wrote:
> > The statements (a) through (d) translate to the fact that the
> > operation should have an OPTIONAL "pattern" attribute that describes the
> > actual message exchange pattern being expressed in the operation. The
> > statement also concludes that if the User is modeling one of the
> predefined
> > MEPs, the "pattern" value is implicit.
>
> No.
>
> We had that nightmare with WSDL 1.1.  Just look at the pattern and
> figure out from there what it is!  That means that there can only be one
> request-response, one in-only, one notification, one
> solicit-response--even though the latter two are noted as
> "insufficiently defined".  They can't be replaced, because you're
> supposed to figure out the pattern from the sequence of elements in the
> content.
>
> Really bad idea.
>
> > Why not make the"pattern" attribute optional [With No Default Value],
> and
>
> We had this argument back when the issue was resolved.  The arguments in
> favor of implicit pattern definition were all laid down then, and all
> have the same problem: they suggest that the definitions that we have
> created are the only or the best patterns available.
>
> You can't distinguish between in-only and robust in-only from the
> content of an operation.  This was the reason that we were able to avoid
> "implicit" definitions of any operation containing a single message
> with direction in; you have to specify the pattern attribute in order to
> let people reading the WSDL know which one it is.
>
> The same ought to hold for in-out with respect to in-optional-out, but
> it was decided that in-out is so common a pattern that, to make it
> easier for those writing WSDL by hand, the "shorthand" to indicate this
> pattern is to leave the attribute out.  That's the reason that we have
> the attribute marked optional with a default value.
>
> > add an assertion stating that if the User is modelling an operation
> whose
> > MEP is not one of those predefined MEPs, the pattern attribute should be
>
> Since it's not possible to distinguish between the predefined MEPs
> without a scorecard^Wpattern attribute, this is not a feasible solution.
>
> > mandatorily present on the opertion. Needless to mention, having a
> default
> > value is bound to violate the so-called referential integrity.
>
> Yup.  Let's dump it, and require pattern in all cases, okay?
>
> We already know that the solution proposed here (implicit determination
> of the value of the pattern property based on the content of the
> operation) is unreliable for WSDL 1.1, and perfectly infeasible for WSDL
> 2.0 where the content model of the operation won't unambiguously
> identify the MEP.
>
> (*ow*, *ow*, stop!  Mo-o-ooom!  Make Sanjiva stop *hitting* me!)
>
> Amy!
> --
> Amelia A. Lewis
> Senior Architect
> TIBCO/Extensibility, Inc.
> [email protected]
>



-- 
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

-Ramkumar Menon
A typical Macroprocessor