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