HTTP binding: Misalignment between IRI style and application/x-www-form-urlencoded serialization, and between Multipart style and multipart/form-data serialization

In our previous last call, we went back and forth about the design of
the operation style (applying to an operation or a message?) and the
generality of the URI and Multipart styles (limited to in-out or
not?).

I am afraid that we ended up in a situation which isn't bulletproof.
However, it should be fairly simple to fix it.

== Issue ==

The IRI style, like all styles, applies to an operation. We made it
constrain the first message of the MEP in use in order not to
constrain it to in-out, in-only and robust-only unnecessarily in case
somebody wants to use it for say an out-in operation.

This constraint expressed in this style is for use for a serialization
as an IRI of the instance data, by the
application/x-www-form-urlencoded serialization. However, this
serialization talks about serializing an input message (section 6.9.1
Serialization as "application/x-www-form-urlencoded"):

  This serialization format is designed to allow a Web service to
  produce a IRI based on the instance data of input messages. It may
  only be used for interface operation using the IRI Style format as
  defined in 4.2 IRI Style.

With the current specification, you could use the IRI style an a
out-in operation, which would constrain the first message, the output
message, and use the application/x-www-form-urlencoded serialization
on the second message, the input message, which is not constrained
by our IRI style. This is broken.

The application/x-www-form-urlencoded can be used only for the
messages that are constrained by the IRI style, i.e. only for the
first message of an operation.

As a side note, I don't think that we mean to say limit the
serialization to a Web service; we should say "Web service or client".

== Proposal ==

Here is some new proposed text for section 6.9.1:

  This serialization format is designed to allow a client or Web
  service to produce an IRI based on the instance data of a message.
  It may only be used when binding Interface Operation components
  using the IRI Style format as defined in 4.2 IRI Style, i.e. this
  serialization format may only be used to serialize the initial
  message of an interface operation.

  Specifically, for the HTTP binding defined in this section (6. WSDL
  HTTP Binding Extension), "application/x-www-form-urlencoded" MAY be
  used as a value for the {http input serialization} property of the
  Binding Operation component, but MUST NOT be used as a value as a
  value for the {http output serialization} or {http fault
  serialization} properties.

And add the following to Table 6-3. Mapping from XML
Representation to Binding Operation component Extension Properties to
note that it's an error for {http output serialization} or {http
fault serialization} to use this value:

  {http output serialization}

     The actual value of the whttp:outputSerialization attribute
     information item, if present; otherwise, the default value as
     defined in 6.3 Default Binding Rules, computed based on the value
     of the {http method} property. It is an ERROR for this property
     to have the value "application/x-www-form-urlencoded" (see
     section 6.9.1 Serialization as
     "application/x-www-form-urlencoded").

  {http fault serialization}

     The actual value of the whttp:faultSerialization attribute
     information item, if present; otherwise "application/xml". It is
     an ERROR for this property to have the value
     "application/x-www-form-urlencoded" (see section 6.9.1
     Serialization as "application/x-www-form-urlencoded").

== Similar issue ==

A similar issue exists in section 6.9.3 Serialization as
"multipart/form-data", and similar text should fix the problem.

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/