Proposal for LC333

This message discharges the action item we got around LC333.

For simplicity, in this proposal we limit ourselves to discussing
the issue as it applies to the wsoap:mepDefault attribute.
The same approach can be used (with the necessary mechanical adjustments)
to the following HTTP binding attributes: whttp:methodDefault,
whttp:queryParameterSeparatorDefault, whttp:transferCodingDefault.

The issue is quite simple to describe, although some of the details are
tricky. Basically, the SOAP and HTTP bindings don't take into account
the possibility that an Endpoint component specify an interfaceless
binding, i.e. a Binding component whose {interface} property has no

At a high level, there are at least a couple of problems with part 2.

The first one is that the wsoap:mepDefault attribute is syntax-only
(i.e. it's not reflected in any component model property), so its
usage is limited to explicitly specified Binding Operation components.
In other words, since interfaceless bindings don't define Binding
Operation components, currently they cannot use the mep default.

The second issue is that the default binding rules are written in a
way that does not cover the case of Interface Operation components
for which there is no Binding Operation component, i.e. precisely
the case of interfaceless bindings.

The proposal is to introduce a new component model property in part 2
of the spec, i.e. an optional {soap mep default} property on the Binding
component. We envision this to be done in a new, separate section similar
to 5.5. The value of the property is mapped from the wsoap:mepDefault
attribute in a straightforward way.

The description of the property would resemble that of the {soap mep}
property in section 5.7.2. Here's some text (wordsmithing welcome):

{soap mep default} OPTIONAL. A xs:anyURI, which is an absolute IRI as
defined by [IETF RFC 3987], to the Binding component. The value of this
property identifies the default SOAP Message Exchange Pattern (MEP) for
all the Interface Operation components of any Interface component that
uses this Binding component.

Then in section 5.7.4 we need to modify the mapping rule for the {soap mep}
property to use the newly introduced property. Since we need to expand the
default binding rules to cover interfaceless bindings anyway, we propose
to change this section to simply store the value of the wsoap:mep attribute,
if any, in the {soap mep} property, making the property optional.
The existing rules about a MEP being required and on using the
wsoap:mepDefault attribute would be folded in section 5.10.3 "Default
Binding Rules" (more on this below).

Here's the proposed new text:

{soap mep} 	The actual value of the wsoap:mep attribute information item,
                 if present, empty otherwise.

To harmonize with it, the definition of the {soap mep} property in
section 5.7.2 would be amended as follows:

{soap mep} OPTIONAL. A xs:anyURI, which is an absolute IRI as defined
by [IETF RFC 3987], to the Binding Operation component. The value of this
property identifies the SOAP Message Exchange Pattern (MEP) for this
specific operation.

Finally, the rule for selecting a SOAP MEP in section 5.10.3 (Default
Binding Rules) needs updating.

Proposed text:

SOAP MEP Selection. For a given Interface Operation component, if there is
a Binding Operation component whose {interface operation} property matches
the component in question and its {soap mep} property has a value, then
the value of the {soap mep} property. Otherwise, the value of the Binding
component's {soap mep default}, if any. Otherwise, if the Interface
Operation component's {message exchange pattern} property has the value
"", then the URI
"" identifying the SOAP
Request-Response Message Exchange Pattern as defined in [SOAP 1.2 Part
2: Adjuncts]. Otherwise (i.e. if the Interface Operation component
has any other value for the {message exchange pattern} property), it
is an error.

I would also argue that calling these rules "default binding rules"
is somewhat of a misnomer, since (with the proposed changes), they now
describe the rules that are used in all cases to compute certain values
which are necessary for the correct operation of the SOAP binding.
It would make more sense then to call them "binding rules" and make
the necessary edits to the HTTP method selection and IRI generation


Received on Wednesday, 26 October 2005 19:20:31 UTC