RE: [lc132]: Proposal: Reference Parameters vs. complete EPRs

Yes it does.  Your ability to avoid sloppiness is greater than mine ;-).
Thanks!

> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM]
> Sent: Tuesday, April 18, 2006 8:35 AM
> To: Jonathan Marsh
> Cc: public-ws-addressing@w3.org
> Subject: Re: [lc132]: Proposal: Reference Parameters vs. complete EPRs
> 
> I'm generally in favor of this proposal but I have a question about
> one aspect of it, see below.
> 
> On Apr 17, 2006, at 1:06 PM, Jonathan Marsh wrote:
> > 4.x Extending WSDL Endpoints with an EPR
> > The wsa:EndpointReference element (see Web Services Addressing 1.0
> > - Core[WS-Addressing-Core]) MAY be used as an extension child
> > element of the wsdl20:endpoint or wsdl11:port elements. When
> > present, the value of the [destination] message addressing property
> > of the EPR MUST have the same value as the {address} property, if
> > any, of the endpoint component. For WSDL 1.1 the [destination]
> > message addressing property MUST have the same value as the address
> > supplied by the binding extension.  For example, in a SOAP 1.1 port
> > described using WSDL 1.1, the location attribute of the
> > soap11:address element must have the same value as the wsa:Address
> > element.
> 
> Its not clear in the above what the "When present" refers to: a
> wsa:EndpointReference element, or the [address] property (note that
> an EPR doesn't have a [destination] MAP, only messages have those) ?
> I note that [address] is mandatory in an EPR so I think I'd rephrase
> the above as follows:
> 
> "A wsdl20:endpoint or wsdl11:port element MAY be extended using a
> child wsa:EndpointReference element. When extended this way, the
> [address] property of the child EPR must match the {address} property
> of the endpoint component (WSDL 2.0) or the address value provided by
> the relevant port extension (WSDL 1.1). For example, in a SOAP 1.1
> port described using WSDL 1.1, the location attribute of the
> soap11:address element must have the same value as the wsa:Address
> element."
> 
> Does this capture the intent ?
> 
> Marc.
> 
> >
> >
> >
> >
> > 4.x.1 WSDL 2.0 Component Model Changes
> > Use of WS-Addressing adds the following OPTIONAL properties to the
> > WSDL 2.0 component model:
> >
> > A property of the Endpoint component, named {endpoint reference}.
> > This property is of type wsa:EndpointReference, with a cardinality
> > of 1. The property has the value of the wsa:EndpointReference
> > element used as a child of wsdl20:endpoint, if any.  If no such
> > extension exists, this property is absent.
> >
> >
> >
> > Although there are other ways to do it, I would probably reorganize
> > and renumber Section 4 as follows:
> >
> >
> >
> > 4. Specifying Message Addressing Properties in WSDL
> >     4.1 Extending WSDL Endpoints with an EPR
> >
> >     4.2 Destination
> >     4.3 Reference Parameters
> >
> >     4.4 Action
> >
> >
> > From: public-ws-addressing-tests-request@w3.org [mailto:public-ws-
> > addressing-tests-request@w3.org] On Behalf Of Jonathan Marsh
> > Sent: Tuesday, April 11, 2006 4:43 PM
> > To: public-ws-addressing-tests@w3.org
> > Subject: Reference Parameters vs. complete EPRs
> >
> >
> >
> > Section 4.3 ReferenceParameters
> >
> > The current mechanism for embedding EPR information in a WSDL
> > endpoint/port misses an opportunity to provide some useful
> > benefits, which would be regained by embedding the whole EPR rather
> > than just the ReferenceParameters element.
> >
> >
> >
> > Address information can appear in WSDL in a variety of ways.  In
> > WSDL 1.1 it can appear in the wsoap11:element attribute, or in the
> > wsoap12:address element if the WSDL 1.1 Binding Extension for SOAP
> > 1.2 submission [1] (acknowledged by W3C yesterday) is used.  In
> > WSDL 2.0 it can appear in the wsdl:endpoint/@address attribute.
> > Allowing wsa:Address to extend the endpoint/port provides a
> > consistent way to serialize addresses regardless of the WSDL and
> > SOAP version in use.
> > Deconstructing an EPR to serialize it into WSDL requires special
> > serialization code.  Instead of having a single codepath for
> > serializing an EPR, we need a WSDL-specific way to serialize just
> > the ReferenceParameters.
> > Multiple serializations become increasingly painful as EPR
> > extensions are developed, which would each have to be serializable
> > in two flavors - EPR extensions, and endpoint/port extensions.
> > Every EPR extension would also have to be defined both as an EPR
> > extension and as a WSDL extension, making the development of EPR
> > extensions more complex.
> > We currently use 2004/08 EPRs as WSDL extensions without
> > deconstructing them, and we'd like a consistent model between the
> > submitted and standardized models.
> >
> >
> > We therefore request that section 4.3 specify that a whole EPR can
> > be embedded in an endpoint/port.  If both an EPR and one of the
> > *:address mechanisms are present, the address values MUST match.
> >
> >
> >
> > [1] http://www.w3.org/Submission/wsdl11soap12/
> >
> >
> >
> >
> >
> >  [  Jonathan Marsh  ][  jmarsh@microsoft.com  ][  http://
> > spaces.msn.com/auburnmarshes  ]
> >
> >
> >
> >
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
>

Received on Tuesday, 18 April 2006 18:52:03 UTC