When we discussed this on the implementors call yesterday I was happy with
your explanation. Output and outfault messages don't map to HTTP requests
and infaults are not used with the 3 MEPs defined by the spec Part 2.
I'm now just wondering about user-defined MEPs ... about the possibility
that the {http location} property might be used with some user-defined MEP
like in-out-in or in-out-in-out with a fault ruleset that permits an
<infault> on the second 'in'. If the spec needs to allow for user-defined
MEPs, then perhaps the wording should include 'infault' as well as
'input'.
For example:
"Strings enclosed within single curly braces MUST be element names from the
instance data of the input or infault message."
John Kaputin
On 12/19/06, Jonathan Marsh <[EMAIL PROTECTED]> wrote:
I don't think this binding supports mapping an output or fault to an HTTP
request message. It only supports the in-out, in-only, and robust-in-only
MEPs, in which the input message maps to the HTTP request.
*Jonathan Marsh* - http://www.wso2.com -
http://auburnmarshes.spaces.live.com
------------------------------
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On
Behalf Of *John Kaputin (gmail)
*Sent:* Monday, December 18, 2006 3:56 AM
*To:* [EMAIL PROTECTED]
*Cc:* woden-dev@ws.apache.org
*Subject:* Clarifying assertion for HTTP Location
Part 2 section 6.7.1.1 Construction of the request IRI using the {http
location} property.
This section contains the assertion:
"Strings enclosed within single curly braces MUST be element names from
the instance data of the input message."
I assume 'input message' here refers generically to any input data for the
HTTP request (i.e. to a WSDL input, output or fault message element). To
make this clearer and to keep it consistent with the description at
hyperlink "instance data", perhaps you could restate this something like:
"Strings enclosed within single curly braces MUST be element names from
the instance data of the input, output or fault message."
regards,
John Kaputin.
