- From: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
- Date: Thu, 2 Oct 2003 09:16:38 -0700
- To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, "Roberto Chinnici" <Roberto.Chinnici@Sun.COM>
- Cc: <www-ws-desc@w3.org>
> Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] writes:
> "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com> writes:
> >
> > However, I do agree that the direction information is redundant
between
> > the operation children and the values specified within the pattern
URI
> > definition; if that redundancy bothers people, they we should
consider
> > removing the other source.
>
> What I am trying to fix is the {direction} property of message
> reference components.
Agreed
> The point I keep making, but apparently not
> getting through, is that message references *do not* have such
> a property.
At an abstract level, the Message Reference component (Section 2.4) must
have a {direction} property. Currently it is populated by the local name
of the element information item (Table 2-4), and it is an error if the
pattern URI definition specifies a different value (which might not be
in the spec yet).
> Each message reference *absolutely* has a direction,
Agreed
> but that is *already* set by the pattern URI definition.
I agree that the local name of the element information item is redundant
with the pattern URI definition.
> Thus,
> I believe that we should get rid of this property
To make the component model work, we need a property for each
interesting characteristic.
> and simply
> record in the spec that the element name ("input" vs. "output")
> MUST match with the direction property of the message reference
> as specified by the pattern URI definition.
Agreed
> To me. this is *totally* independent of what we do ref short-cut
> syntax for common patterns.
OK
Received on Thursday, 2 October 2003 12:19:02 UTC