Re: problem with pattern attribute definition?

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.
alewis@tibco.com

Received on Friday, 16 February 2007 20:34:54 UTC