Re: problem with pattern attribute definition?

Hi Gurus,

Quoting Sanjiva
 - "the default value of @pattern is in-out, no matter what's
inside the <operation>"

Correct me if I am wrong [and miserably wrong :-)]

I would assume the User could have the following options while designing
operations within the WSDL.

a) While desiging the WSDL, the User decides to model the operation with one
of the predefined MEPs. The User [optionally] annotates the operation with
the intended MEP, and then models the operations in accordance with the MEP.

b) While designing the WSDL, the User decides to model the operation with
one of the predefined MEPs. The User models the interface message
references/faults and then "optionally" annotates the operation with the MEP
pattern that is congruent with the modeled IMR and IFRs.

c) While desiging the WSDL, the User decides to model a custom message
exchange pattern. He "mandatorily" annotates the operation with the intended
custom MEP pattern, and then mandatorily models the IMR/IFRs in accordance
with the MEP.

d) Vice-Versa of (c).

These statements make me think "Whats the Key between the two ?
Is it the pattern URI ? - Which means that  the User makes a statement that
the operation definition conforms to the specific MEP mentioned in the
pattern URI;  or is it the IMRs/IFRs within the operation that determine
what MEP pattern is being used in the operation ?
I would rather stick with the former - that clearly annotates the operation
with the intent to use a specific MEP, and also lays the guidelines on how
the IMRs and IFRs need to be modeled to adhere to the specified pattern.

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.

Why not make the"pattern" attribute optional [With No Default Value], and
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
mandatorily present on the opertion. Needless to mention, having a default
value is bound to violate the so-called referential integrity.

rgds,
Ram


On 12/10/06, Sanjiva Weerawarana <sanjiva@wso2.com> wrote:
>
>
> (Just happened to drop in on the list and caught this discussion!)
>
> Amelia A Lewis wrote:
> >> I recall at one point in time we discussed having a default value.
> >> However, these spec doesn't seem to indicate that we went that way.
> >
> > It may have gotten dropped in editing, then.  I remember the argument
> > well, if only because I was on the losing side, having fought the good
> > fight.  The result of it was that in-out is considered to be so common
> > an idiom that it ought *not* require the pattern attribute.  That is,
> > we ended up setting the in-out pattern as the default value of the
> > pattern attribute, as the above statement indicates.
> >
> >> To resolve this, either 1) remove the otherwise clause
> >
> > I believe that this would reverse the resolution of the issue that was
> > raised.
> >
> >> 2) or, define the default and make the attribute OPTIONAL
> >
> > I believe that this was the previous resolution.  I think that the
> > failure to mark the attribute OPTIONAL is simply an oversight, when the
> > previous resolution was implemented.  If someone can identify the
> > issue, I believe that the record of the issue and its resolution will
> > support this, and I say this as the primary *opponent* of the
> > resolution adopted.
>
> I also remember this argument well .. and I actually argued for more
> defaulting: if there was only an <input> in an <operation> default to
> in-only etc..
>
> However, I recall losing that part of the battle :(. So +1 for doing what
> Amy recalls- the default value of @pattern is in-out, no matter what's
> inside the <operation>.
>
> Bye,
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> email: sanjiva@wso2.com; cell: +94 77 787 6880; fax: +1 509 691 2000
>
> "Oxygenating the Web Service Platform."
>
>


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

-Ramkumar Menon
A typical Macroprocessor