W3C home > Mailing lists > Public > public-ws-addressing@w3.org > May 2005

Re: Formal objection to the binding of [reference properties] in SOAP

From: Conor P. Cahill <concahill@aol.com>
Date: Mon, 23 May 2005 08:22:47 -0400
To: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>
cc: "public-ws-addressing@w3.org " <public-ws-addressing@w3.org>, "Mark Little" <mark.little@arjuna.com>, "Rich Salz" <rsalz@datapower.com>, "Tom Rutt" <trutt@us.fujitsu.com>, "Jacques Durand" <JDurand@us.fujitsu.com>, "Bob Freund" <Bob.Freund@hitachisoftware.com>, "nishiy_e@itg.hitachi.co.jp" <nishiy_e@itg.hitachi.co.jp>, "Mischkinsky,Jeff " <JEFF.MISCHKINSKY@oracle.com>, "Ugo Corda" <UCorda@SeeBeyond.com>, "Pete Wenzel" <pete@SeeBeyond.com>, "Glen Daniels" <gdaniels@sonicsoftware.com>, "Arun Gupta" <Arun.Gupta@Sun.COM>, "Marc Hadley" <Marc.Hadley@Sun.COM>, "David Hull" <dmh@tibco.com>, "Amelia A Lewis" <alewis@tibco.com>, "Mark Nottingham" <mark.nottingham@bea.com>, "Hugo Haas" <hugo@w3.org>, Philippe Le Hégaret <plh@w3.org>
Message-ID: <4291CB17.6040509@aol.com>



Anish Karmarkar wrote on 5/16/2005, 3:16 PM:


 > Wrapping the reference parameters with a WS-Addressing specific
 > element with a clear and well-defined semantics would prevent
 > the problems outlined above. There are two approaches that
 > would accomplish this --

 > 1) Make wsa:To an EPR
 > 2) Define a new SOAP Header Block

While I agree with many of the concerns that are expressed in this
objection, I have significant concerns as to the proposed solutions
as well.

my main concern:

    1) The proposals cause the data added by the deference of
       an EPR to show up in a non-standard location (e.g if I
       had a standard that required a MyHeader header on an
       invocation of a service, there is no way for the EPR
       to get this to happen unless I force the caller to
       semantically understand this header pull it out of
       metadata and place it into the MyHeader location -- or
       I have to change my existing standard to allow the
       header to be placed in a different location)

I'm OK with allowing this behavior, I just don't want to prohibit
the existing behavior as well.

It seems that we need something along the following:

    a) the ability for the generator of an EPR to insert specific
       headers into a message that is dereferencing the EPR.  The
       user of this EPR may or may not understand the semantics of
       this header.

    b) the ability for the generator of an EPR to insert
       arbitrary data in a catch-all WSA location specified
       in the WSA spec (such as the alternatives proposed
       in this message).  The user of this EPR may or may not
       understand the semantics of this data.

    c) the ability for the generator of an EPR to provide
       sematically important information to the user of an
       EPR that may or may not end up in a message generated
       by the user (it may impact how the message is generated,
       it may or may not be copied to some place in the message).

As far as the "isReferenceParameter" issue, I completely agree with the
issue related to adding an attribute and suggest that there be
something along the lines of a "ReferenceParameterList" element
that lists all of the reference parameters.

Conor
Received on Monday, 23 May 2005 12:23:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:05 GMT