problem with pattern attribute definition?

Heylas,

So, the pattern AII is REQUIRED (2.4.2 ed copy, bullet 3). 
But if it *doesn't exist*, we supply a default value
(2.4.2.2, final sentence).

If that's the way that we always describe defaults (required
attribute, which if it isn't there has a value anyway), then
our description is really painfully awkward.  Is this a
consequence of describing the "XML representation"
via the infoset?  Is it boneheaded of me to think that if I
see "the pattern attribute information item is
required" that pattern will always appear on operation?

Heh.  Can XPath retrieve the value of a defaulted attribute?
 That's not apropos of much of anything, mind.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewistibco.com

Now CR125: 

We could (and should IMO) remove the phrase ";
otherwise
'http://www.w3.org///wsdl/in-out'" from the second row of Table 2.4.

Jonathan Marsh - http://www.wso2.com - http://auburnmar
shes.spaces.live.com
 

> -----Original Message-----
> From: www-ws-desc-requestw3.org
[mailto:www-ws-desc-requestw3.org] On
> Behalf Of Amelia A Lewis
> Sent: Thursday, December 07, 2006 10:36 AM
> To: www-ws-descw3.org
> Subject: problem with pattern attribute definition?
> 
> 
> Heylas,
> 
> So, the pattern AII is REQUIRED (2.4.2 ed copy, bullet
3).  But if it
> *doesn't exist*, we supply a default value (2.4.2.2,
final sentence).
> 
> If that's the way that we always describe defaults
(required attribute,
> which if it isn't there has a value anyway), then our
description is
> really painfully awkward.  Is this a consequence of
describing the "XML
> representation" via the infoset?  Is it boneheaded
of me to think that if
> I see "the pattern attribute information item is
required" that pattern
> will always appear on operation?
> 
> Heh.  Can XPath retrieve the value of a defaulted
attribute?  That's not
> apropos of much of anything, mind.
> 
> Amy!
> --
> Amelia A. Lewis
> Senior Architect
> TIBCO/Extensibility, Inc.
> alewistibco.com

Arthur,

On Fri, 8 Dec 2006 11:24:47 -0500
Arthur Ryman <rymanca.ibm.com> wrote:
>I agree this is a problem. If an AII is REQUIRED, it
MUST be present
>in the XML document. Therefore, the following statement
is
>inconsistent:
>
>The actual value of the pattern attribute information
item; otherwise 
>'http://www.w3.org///wsdl/in-out'. 

Good; that's what I thought as well.  That's how we do other
properties, such as messageLabel, that have default values.

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

>The component model propery is REQUIRED in either case.

Yes; no change is needed there.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewistibco.com

(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: sanjivawso2.com; cell: +94 77 787 6880; fax: +1
509 691 2000

"Oxygenating the Web Service Platform."

Ramkrishna 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.
alewistibco.com