RE: Comment on Fragment Identifiers

See below.

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
 
> -----Original Message-----
> From: David Orchard [mailto:[email protected]]
> Sent: Thursday, December 21, 2006 5:27 PM
> To: Jonathan Marsh; Amelia A Lewis; Paul Cotton
> Cc: [email protected]; [email protected]; [email protected]
> Subject: RE: Comment on Fragment Identifiers
> 
> Ah, very very interesting.  I for one had forgotten that the meps had
> in|out as component names rather than the syntax local names of input
> and output.
> 
> Now just to confirm my understanding.  If the wsdl meps are used, they
> have no multiple messages in a single direction so component names are
> sufficient and they are used as the message labels.  If different meps
> are used, particularly a mep that has multiple messages in a single
> direction, then each message will have a unique message label and that
> will be used.

Essentially.  More precisely:
  If the wsdl meps are used, they have no multiple placeholder messages in a
single direction so the unique-per-direction message labels can be used.  If
different meps are used, with no multiple placeholder messages in a single
direction, the unique-per-direction message labels can be used.  If a
different mep is used which has multiple messages in a single direction,
then one is required to disambiguate the message references with the
messageLabel attribute on each <input> or <output> corresponding with that
placeholder message in the MEP.

> I think that WSDL-only processing can still generate and evaluate the
> component identifiers because the extensibility point is only in the #
> of messages, not in the component names.

Don't quite understand this.  The MEP extensibility point includes
increasing the number of placeholder messages in a single direction.  The
messageLabel is the identifier for each placeholder message.  As such it
appears in the component designator.

Remember, The differences between <input> and <output> are exposed in the
{direction} property, not the {message exchange pattern}.  Perhaps if
{direction} was an enumeration of "input"|"output" instead of "in"|"out" it
would be less confusing and closer to your Close To The Infoset (CTTI)
preference, though it would lose its grammatical aesthetic.

> Cheers,
> Dave
> 
> > -----Original Message-----
> > From: Jonathan Marsh [mailto:[email protected]]
> > Sent: Thursday, December 21, 2006 4:06 PM
> > To: 'Amelia A Lewis'; 'Paul Cotton'
> > Cc: [email protected]; [email protected]; David
> > Orchard; [email protected]
> > Subject: RE: Comment on Fragment Identifiers
> >
> > Sorry, not the first time I've messed up the capitalization -
> > the {direction} token is an enumeration of "in" and "out"
> > (note lack of capitalization!), and I really need to
> > double-check which property values are capitalized and which
> > aren't before putting fingers to keyboard...
> >
> > <input> maps to {direction} = "in".  <output> maps to
> > {direction} = "out".
> > But as Amy says, when you can have multiple messages in a
> > single direction within a MEP, {direction} is insufficient to
> > identify them.  {message label} provides a unique token for
> > messages within a MEP with which to identify them.
> >
> > This is not terribly obvious from a cursory read of the spec
> > because of our defaulting rules, that will automatically map
> > {message label} to "In" or "Out" for the MEPs we define, so
> > it looks to the casual user like the <input> is causing
> > {message label} = "In" when in fact what's happening under
> > the covers is a little more sophisticated and general-purpose.
> >
> > Jonathan Marsh - http://www.wso2.com -
> > http://auburnmarshes.spaces.live.com
> >
> > > -----Original Message-----
> > > From: Amelia A Lewis [mailto:[email protected]]
> > > Sent: Thursday, December 21, 2006 2:58 PM
> > > To: Paul Cotton
> > > Cc: [email protected]; [email protected];
> > > [email protected]; [email protected]; [email protected]
> > > Subject: Re: Comment on Fragment Identifiers
> > >
> > > Not replying for the group, but I believe that I understand the
> > > question and the mistaken assumption within it.  :-)
> > >
> > > On Thu, 21 Dec 2006 14:44:42 -0800
> > > Paul Cotton <[email protected]> wrote:
> > > >We are wondering why the designators use "in" and "our" given that
> > > >the actual WSDL message labels are "input" and "output"?
> > >
> > > In fact, we do not use "in" or "out".  We use the messageLabel
> > > specified in the message exchange pattern.  In part two, all of the
> > > message labels in all of the message exchange patterns are
> > restricted
> > > to the set "In" and "Out" (note capitalization).  In the particular
> > > example cited, which relies on the in-out pattern, there
> > are two messages, one labelled "In"
> > > and one labelled "Out".
> > >
> > > "input" and "output" are nowhere used as message labels.
> > They are the
> > > local names of element information items in the WSDL 2.0 syntax.
> > > These element information items are not referenced in the syntax of
> > > component designators, although as a class, they can be identified
> > > with the combination of .interfaceMessageReference() with
> > their unique
> > > identifiers (ticketAgent/reserveFlight/In and
> > > ticketAgent/reserveFlight/Out in the example).
> > >
> > > >Was this a conscious decision of the WSDL WG?
> > >
> > > Yes.  There may be more than one [input] element
> > information item or
> > > more than one [output] element information item in an interface
> > > operation in a valid WSDL, but all of the {messageLabel}
> > properties of
> > > all of the {interfaceMessageReference} components of an interface
> > > operation MUST be unique.
> > >
> > > >This apparent discrepancy can be seen in the examples in
> > Appendix C.2
> > > >of the WSDL 2.0 Candidate Recommendation [1].
> > > >[1] http://www.w3.org/TR/2006/CR-wsdl20-20060327/#Iri-ref-ex
> > >
> > > I hope that the above explanation clarifies matters.  It
> > may behoove
> > > us to make some sort of explanation of this sort publicly
> > available,
> > > as it appears to be on its way to being a FAQ.
> > >
> > > Amy!
> > > --
> > > Amelia A. Lewis
> > > Senior Architect
> > > TIBCO/Extensibility, Inc.
> > > [email protected]
> >
> >