Re: Clarifying assertion for HTTP Location

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:* [email protected]
> *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.
>
>