Comments on Mike's comments (with a little trimming to take out things
you don't need to read again):
Mike Edwards wrote:
OF8761B854.02F3450C-ON80257515.003F3869-80257515.0045D6E0@uk.ibm.com"
type="cite">
Folks,
Comments inline as <mje>...</mje>
The following comes in two parts - moving the
gist of what is the existing
section 4.4, which is the original text that turned into (the now
deleted)
section 4.3 below, and the revision for the rest of section 4. First,
the normative statement about mapping to WSDL:
Section 2.2, paragraph #1 currently reads:
When binding.ws is used on a service or reference with an interface
that
is not defined by interface.wsdl, then a WSDL portType for the service
or reference is derived from the interface by the rules defined for
that
SCA interface type.
I suggest changing this to:
When binding.ws is used on a service or reference with an interface
that
is not defined by interface.wsdl, then a WSDL portType for the service
or reference is derived from the interface by the rules defined for
that
SCA interface type. A conformant SCA runtime MUST raise an error
if the interface does not map to a WSDL portType.
<mje>I suggest
using
the term "An SCA runtime MUST" rather than "A conformant
SCA runtime MUST" - the question of conformance should be left to
be dealt with elsewhere</mje>
Agreed.
OF8761B854.02F3450C-ON80257515.003F3869-80257515.0045D6E0@uk.ibm.com"
type="cite">And finally, here's the replacement for
section four,
including all the edits we discussed today.
4 Transport Binding
The binding.ws element provides numerous ways to
specify
exactly how messages ought to be transmitted from or to the reference
or
service. Those ways include references to WSDL binding elements from
the
@wsdlElement attribute, policy intents, and even vendor extensions
within
the binding.ws element. However, all of those ways to indicate how
messages
get carried happen to be optional. This section describes the defaults
that MUSTto be used if the specific transport
details
are not otherwise specified.
4.1 Intents
So as to narrow the range of choices for how
messages are
carried, the following policy intents affect the transport binding.
- soap
This indicates that messages MUST be transmitted using SOAP. One or
more
SOAP versions can be used.
- soap.1_1
Messages MUST be transmitted using only SOAP 1.1.
- soap.1_2
Messages MUST be transmitted using only SOAP 1.2.
4.2
Default Transport Binding Rules
4.2.1 WS-I Basic Profile Alignment
To align to WS-I Basic Profile, the resulting WSDL
port
mustneeds to be all document-literal, or all
rpc-literal
binding (R2705).
This means, for any given portType, for all messages referenced by all
operations in that portType, either
- that every message part references an XML Schema
type
(rpc-literal pattern)
- or that every message references exactly zero or
one XML
Schema elements (document-literal pattern)
A portType
that does not fit one of these two patterns MUST be treated as an error
by a conforming implementation.
<mje>A portType
which
comes from where?? I think some explanation of what entities are
being processed is necessary here - if this is simply the portType from
the <interface/> (directly or derived by mapping) then say so.
</mje>
<mje>There is
that
"conforming implementation" term again - "SCA runtime"
is the agreed term</mje>
I think we agreed in the call that this would be:
"For a service element, the portType from the service's interface or
derived from the service's interface MUST fit one of these two
patterns."
OF8761B854.02F3450C-ON80257515.003F3869-80257515.0045D6E0@uk.ibm.com"
type="cite">
The rest of this section assumes the short-hand
reference
of a "rpc-literal" or "document-literal" pattern, depending
on which of the two bullet points above it matches.
4.2.2 Default Transport Binding Rules
In the event that the transport details are not
otherwise
determined, a conforming implementation MUST enable the following
configuration:
- HTTP-based transfer protocol
- Except when an intent or policy mandates the use
of only
SOAP 1.2,
supportgenerate bindings for SOAP 1.1
<mje>I'd rewrite this as follows: Bindings for SOAP 1.1 are
used, except where an intent or a policy is applied which mandates the
use of SOAP 1.2 in which case Bindings for SOAP 1.2 are
used.</mje>
One point here, which I agree with, is that Mike wants to start with
the assertion, not the exception. Another point here is that Mike
wants this to read something like "Bindings for only SOAP 1.1 are used,
..." That is, the default is to generate SOAP 1.1 bindings and nothing
else, unless policy says to generate SOAP 1.2 bindings, and nothing
else.
My take is that is a gratuitous over-specification, and violates the
notion of being lenient in what one accepts, and rigorous in what one
produces (the obvious counterpoint to this would be things that pose a
security risk - SQL injection anyone? - but I don't think this is one
of those cases). I like the notion that an implementation is free to
generate bindings for both SOAP 1.1 & SOAP 1.2 as a default, on the
same endpoint, if the implementation thinks it useful.
So my restatement: "Bindings for SOAP 1.1 are provided, and bindings
for SOAP 1.2 can be provided, unless policy is applied that explicitly
restricts this choice to one or the other."
OF8761B854.02F3450C-ON80257515.003F3869-80257515.0045D6E0@uk.ibm.com"
type="cite">
- "literal" format as described in section 3.5
of [WSDL11]
- For document-
lteralliteral
pattern,
each message uses "document" style, as per section 3.5 of [WSDL11].
- For rpc-literal pattern, each message uses "rpc"
style, as per section 3.5 of [WSDL11]. In this case, the child elements
of the SOAP Body element
mustMUST be namespace
qualified with a non-empty namespace name. This namespace MUST be the structural
URI associated with component, with a
"service-name/binding-name"
appended the binding.
<mje>Why this namespace?</mje>
Why not? Seriously, though, the options seem to be:
- Specify nothing (remove this last sentence - the previous
sentence that it must be namespace qualified still stands)
- Specify constraints, but not specific detail, as in, "each
binding MUST use a different namespace"
- Specify an alternate specific choice
- Use the current specific choice.
I can live with any of the options from 2 - 4. I don't think #1 is a
good idea. It was Anish's idea to suggest the current option (#4).
Option #4 has the benefit of being closely tied to the binding itself,
and satisfies the only possible rule I can think of that would make up
#2.
-Eric.
|