My comments inlined below.|
Eric Johnson wrote:
firstname.lastname@example.org" type="cite">Based on
the minutes of the meeting of 2008-05-29, I've made a few
edits. Since I was MIA for the meeting, my understanding of the
discussion might be somewhat misguided. Additions shown with
underscore, deletions shown with strike-through.
As I mentioned in last week's call. I prefer that we do not constraint
the deployer (or the runtime/vendor) on this.
I see one key question worth floating to the top:
Suppose someone puts
<binding.ws/> on a service with no further qualifications. Per
default binding rules in the new proposal, this will enable an endpoint
that supports SOAP
1.1 over HTTP. Must this be the only WSDL 1,1 port for the
could an implementation choose to simultaneously implement a SOAP 1.2
binding, and if it implements an additional binding, must it be at the
same endpoint, or can it be at a different endpoint? Put differently,
if an SCA end-user wants to support both SOAP 1.1 & SOAP 1.2 at the
same HTTP URL:
- Can a vendor automatically expose those two different WSDL
on the same URL endpoint, supporting both SOAP 1.1 & SOAP 1.2, and
the end-user only declares a single <binding.ws/> element?
- Or does the end-user have to define two different binding.ws
elements (and then has to use policy intents to indicate which binding
element is which)
<binding.ws/> means that a <wsdl:port>, which is bound to
the WSDL SOAP 1.1, must be made available. Nothing more.
If there are additional <wsdl:port> elements in the same
<wsdl:service> or in different <wsdl:service> is none of
our business. I.e. out of scope for SCA specifications. Whether
additional <wsdl:port> that are made available have the same
value of <soap:address> or different values that get HTTP
redirected to the same thing, or aliases to the same thing or something
completely different and unconnected -- we shouldn't say. That is for
the deployer/policy czars runtimes to figure out.
Responding to the notes from the meeting:
s/ought to be used/are used/
Simon H. look through the
proposal, appendix B
Scribe: Set of 5 rules, around def
of the name space
Scribe: Comments on the proposal
Scribe: Anish: is the description an
Me: Assuming this is still referring to Appendix B, yes - certainly
Scribe: Simon H: the wording
suggests its a recommended approach
Me: I added text indicating that appendix B is non-normative.
Scribe: Simon N: Should parts be
Scribe: Anish: Importing PortType,
the imported doc will have reference to message and schema, its
importing recursively, if its inlined, correct import has to be
Scribe: No other comments, document
had not yet been reviewed by all
Scribe: Simon N: not consistent
normative language in the proposal
Me: Specifics here would help me out.
Scribe: Bryan: Not clear whether its
WSDL 1.1 or 2.0, should be explicit
Me: Which section?
Scribe: Bryan, comment for section
4.2 (Default Binding)
Scribe: Simon N: should we have
different versions of the section ?
Me: Two versions to cover what? SOAP 1.1 vs SOAP 1.2 or WSDL 1.1
vs. WSDL 2.0? Or something else. I don't see the need, so I think I
Scribe: Mentions SOAP 1.2
Scribe: Section or each item is
compared against policy ?
Scribe: Ambiguous as to it should be
applied whole as opposed to each item separately
Me: My take is that policy is explicit orthogonal to the default
binding. That's why I put in the sentence "In the event that transport
details are not determined elsewhere...". Elsewhere could include
binding details, policy choices, or vendor extensions.
Scribe: In 4.2.1, if there is no
policy, RT may support 1.1 or 1.2, but then second bullet says 1.1
Scribe: Mike E: proposal is not
Scribe: We need author to explain
the intentions to help with wording
Scribe: Go back to Eric for
Me: I think I understand the concern here, but I'm not sure. The
text "the following configuration SHOULD be used" is wonderfully vague.
My intent here was to allow for the possibility that the WSDL
generator could publish multiple WSDL 1.1 "ports" as a consequence of
WSDL generation related to a single binding.ws element. A consequence
of this would be a service that supports both SOAP 1.1 & SOAP 1.2
form invocations at the same endpoint. This results in the apparently
contradictory statements that SOAP 1.1 should be used (bullet 2), but
then that in the case of SOAP 1.2, how to carry the "action" parameter
(bullet 7). This relates to the question I put at the top of this
Scribe: Last bullet of 4.2
Scribe: should not be dependent on
any policy affecting how you generate WSDL
Scribe: Anish: 4.2, except last
bullet should be mandatory
Scribe: Should --> Must
Me: I don't see the value of putting a "MUST" inside of a section
for which the entire contents is a "should."
Scribe: If you don't specify
anything, the WS binding is described in 4.2
Scribe: Simon H: if you don't
specify anything, you are guaranteed interoperability, once you start
specifying things, you don't have interop
Scribe: Anish: Autogeneration of
WSDL should be supported, rules to generate WSDL
Me: ??? I don't think I understand Anish's comment. Once we've
fully specified what the SOAP messages look like, why do we need to
spell out how the WSDL gets generated? What's the use case where the
SCA bindings TC needs to spell this out?
Scribe: Simon N: SOAP version
Scribe: Square bracket with two
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
ought be used if the specific transport details are not otherwise
Given that this is about empty <binding.ws/>, I'm not sure what
So as to narrow the range of choices
for how messages are carried, the following policy intents affect the
This indicates that messages MUST be transmitted using SOAP. One or
more SOAP versions can be used.
Messages MUST be transmitted using only SOAP 1.1.
Messages MUST be transmitted using only SOAP 1.2.
4.2 Default Binding
In the event that the transport details are not
determined elsewhere, a conforming implementation SHOULD enable the
SHOULD be used:
Why is it 'SHOULD'? I expected a 'MUST'.
s/HTTP-based transport/HTTP transfer protocol/
Shouldn't we say that if there is no soap 1.2 policy/intent then it
must be soap 1.1?
Didn't we agree that empty <binding.ws> when using WSDL 1.1 would
be BP complaint. If so, and if we say that then the above 2 bullets can
“literal” format as described in section 3.5
For messages that have a single part, the
message uses “document” style, as per section 3.5 of [WSDL11].
For messages that have multiple parts, the
message uses “rpc” style, as per section 3.5 of [WSDL11]. In this case,
the child elements of the SOAP Body element must be namespace qualified
with a non-empty namespace name.
Also, most of the bullet here talk about WSDL 1.1. Are we saying that
empty <binding.ws> means that WSDL 1.1 must be used? If so, which
I would perfectly happy with given that WSDL 2.0 is not widely
implemented, we should say that.
I think we need to say SOAP 1.1 must be supported. Whether SOAP 1.2 is
supported or not we don't have to say.
For SOAP 1.1 messages, the SOAPAction header
described in section 6.1.1 represents the empty string, in quotes (“”).
For SOAP 1.2 messages, the optional SOAP
feature described in section 6.5 of [SOAP12Adjuncts] does not appear.
All message parts are carried in the body of
4.2.1 SOAP versions
Where no specific version of SOAP has been
dictated, an SCA runtime might support both version 1.1 and version
Should we mandate WSDL 1.1? By mandate I mean that WSDL 1.1 description
must be generated. Whether you also make the equivalent WSDL 2.0
description available we shouldn't say.
WSDL portType or interface
An SCA service has a single interface description.
For the Web Services binding, this interface description MUST be
converted into one or both of a WSDL 1.1 portType or a WSDL 2.0
What if the interface is specified as Java interface? Must the
generated portType not be inlined?
B. Appendix - WSDL Generation
Due to the number of factors that determine how a
WSDL might be generated, including compatibility with existing WSDL
uses, precise details cannot be specified. For example, policy
implementation decisions can affect the way WSDL might be generated.
For reference, and
possible consistency, this
section picks optionssuggests non-normative choices
for some of the various details involved in generating WSDL.
wsdl:definitions/@targetNamespace = <HTTP Base URI> + “/” +
<componentName> + “/” + <serviceName>
import each WSDL
1.1 portType or WSDL 2.0 interface, rather
than putting them inline
= <name of binding> + <SOAP Version> + “Binding”
= <name of the service>
= <name of binding> + <SOAP Version> + “Port”
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in