- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 6 Aug 2003 10:15:16 -0700
- To: <www-ws-desc@w3.org>
-------------------------------------------------------
Thursday 31 July
-------------------------------------------------------
scribe: Jeffsch
09:00 Binding enhancements
Sanjiva proposes [10] to:
1) Drop @interface from binding, since now in service.
2) Allow inlining interface-wide binding within a port and
making binding optional.
3) Define default binding (SOAP doc/lit).
4) Dealing with operation specific SOAPActions.
Kevin proposes to [11]:
1) Allow reuse of parts of bindings through a BindingDetails
element and corresponding references.
Consolidated proposal [12]
Amy's feedback [13]
[10] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0046.html
[11] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0068.html
[12] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0017.html
[13] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0051.html
IBM\Sanjiva and SAP\Kevin presented a set of binding changes.
Motivations include simplifying binding given that the wsdl:message
construct has been removed, and enable site-wide deployment of
binding that could be reused / enforced across a large number of
WSDL documents.
Key points of the proposal include:
1. Drop binding/@interface syntax and {interface} property of Binding
Component
With this change, the binding no longer associates an interface with a
set of concrete wire representation and transport decisions; it would
only define the latter, but the association with the interface would be
done by the service construct.
WSDL 1.1 Proposed change
-------
message
-------
^
|
---------------------- ----------------------
input | output | fault input | output | fault
portType interface
---------------------- ----------------------
^ ^ ^
| |? |
------- ------- |
binding binding |
------- ------- |
^ ^ |
| | |
------- ------------
port endpoint
service service
------- ------------
Posited that one eventually needs to associate the interface, transport
details (and wire rep), and address (a URI). Current association is
like the following:
interface \
| binding \
transport details / | endpoint
|
URI /
Question whether bindings are abstract at the component model or whether
there is a short-cut syntax that is concretized in the component model.
Related discussion whether the binding is a template or a concrete
construct.
This would make the binding component reusable across interfaces only
if it doesn't override default binding values for an operation. In the
latter case, could the binding/@interface AII be retained in that case
to clarify the operation in scope?
ISSUE: if one interface X extends another interface Y in another
namespace N, the operations in X are the union of {[local name],
[target namespace]} for the operations in X and Y. Currently,
operations are referenced within a binding by NCName. Allowed to use
the same NCName for two operations within an interface (including
inheritance) only if they are in separate target namespaces. To refer
to an operation within a binding, how would the namespace N be brought
in to refer to operations within Y? Within the context of an interface,
a QName uniquely identifies an operation (given inheritance); proposed
referring to an operation by QName. This does require specifying two
QNames, but they will (almost) always share a namespace prefix.
DECIDED to change binding/operation/@name from NCName to QName.
In current design, operation is an optional child of the binding
construct and may be included to override default binding settings.
Clarified that current design requires than an endpoint bound to an
interface must support all operations defined by that interface.
1b. Revised proposal to add optional @interface AII to binding/
operation and {interface} property to Binding Operation component.
When binding defaults are overridden for an operation, the binding
component is not reusable across interfaces. Note that if the
@interface AII is on binding/operation, then it can be validated via
XML Schema, but if the @interface AII is on binding, then it cannot
(because XML Schema can't express this type of co-occurrence
constraint). Concern that the binding is sometimes independent of
interface and sometimes not.
Net: the @interface AII (and associated property) moves from binding
to binding/operation. If operation-specific binding details are
specified, then the binding construct is not independent of interface;
otherwise it is.
Questioned the assumptions re: the need to reuse the binding; it
would not be very large, perhaps as little as 3 lines. However,
because the binding currently names the interface, the single construct
cannot be reused across multiple WSDL documents and express, for
instance, a site-wide binding. Pushback that while it is a valid
scenario, we may not have to address it.
What if the reusable, site-wide binding changes? How would a client
endpoint recognize it has changed? Like any other import WSDL issue.
Could one use XInclude to solve part of the problem? Where the child
(children) of a binding are XInclude to the re-usable details? Does
not provide as clean a name to recognize binding details - a URI for
binding details to be included versus the proposed QName for a
reusable binding construct.
Could one define a new extension element for binding that corresponds
to the specific binding details within a (perhaps existing) binding?
Would provide well-known name and would be reusable.
Could use XSL to transform site-specific transform into correct WSDL.
Pushback based on issues with similar approach used in Grid community.
STRAW POLL: Do we want to accept the requirement to allow reusing
transport information across interfaces? 12 in favor, 3 against.
1c. Revised proposal again to make @interface AII optional on binding
(and not defined on binding/operation). If there is no @interface AII
specified, then there MUST NOT be any operation-specific binding
details; if an @interface AII is specified, then there MAY be. QName
of binding/@interface, when present, MUST match QName of
service/@interface.
STRAW POLL: Do we want to adopt this proposal? 11 in favor, 3 against.
No objection to recording this as the status quo.
ISSUE: Should we rename the binding component?
ISSUE: The matching process between the QName of binding/@interface,
when present, and the QName of service/@interface should take
inheritance
into account.
ISSUE: Can we make do with fewer syntactic constraints?
1d. Amendment to 1c to allow omitting the @interface AII on the binding
even when there are operation-specific binding details. The details
would
apply to an operation of the same QName in potentially different
interfaces.
Do not need this modification to allow specifying operation-specific
binding details for an inherited operation. Intention is to enable
additional flexibility in some inheritance cases.
General discussion re: reusing transport details and transport +
operation-specific binding details. Mixing operation-specific binding
details in the binding construct mixes the reusability of that element,
and pushing operation-specific binding details down into
service/endpoint
does allow reusing operation-specific binding details across endpoints.
Concern re: introducing a new top-level construct for the reusable
transport details, partly on the basis of migration from WSDL 1.1 and
partly on the basis of simplicity.
2. Allow service/endpoint to either reference multiple bindings and/or
to have a binding as a child in line.
Discussion re: whether the operation-specific binding details may be
specified within the binding construct and/or within the
service/endpoint
construct (a new location).
Does the general need to specify operation-specific binding details
extend to the need to override reusable binding information? Not
motivated by the site-wide, corporate policy case.
Suggested that one could reference a binding and then override the
general binding with in-line child binding details. Can one define an
uber binding that defines operations from more than one operation?
Proposed allowing endpoint to reference multiple bindings; scenario is
a binding that includes some security considerations while another
includes other, ideally orthogonal binding details. Would resolve
potential conflicts between bindings based on some distance metric;
noted that this problem is latent in current design because someone
could put conflicting HTTP and SOAP binding extension elements within
a binding today.
(As a side note, suggested that the ultimate design of the WG's HTTP
and SOAP bindings may share some components.)
Alternative model would be allow single inheritance of binding, for
example, by adding a @base AII to include a single binding, where
semantics is a lexical inclusion and extension components are resolved
based on lexical distance. Concern re: the complexity of the approach.
OTHER
Have not yet discussed whether the WG is going to define a normative
MIME binding - a partial misnomer since MIME is not a transport; some
work in Part 3 may already address it.
-------------------------------------------------------
12:30 Lunch
-------------------------------------------------------
Scribe: DBooth
Topic: Bindings
Sanjiva's proposal:
http://www.w3.org/2002/ws/desc/3/07/SanjivaBindings1_clean.htm
or original PowerPoint:
http://www.w3.org/2002/ws/desc/3/07/SanjivaBindings1.ppt
[[
Make @interface optional in <binding> to make binding more reusable:
<binding name="ncname" [interface="qname"]>
binding details
<operation name="qname">...</operation>
</binding>
Allow <endpoint> to point to bindings or inline binding:
<service interface="qname">
<endpoint name="ncname"
[bindings="list-of-bindings"]
inlined-bindings
address-binding
</endpoint>
</service>
]]
Amy: list-of-qnames interacts with other things. Will likely
lead to interop problems.
(Sanjiva completes presentation from the morning)
Sanjiva: Semantics of list-of-names:
1. Expand the binding contents listed in the list-of-bindings
and the inlined-bindings, and the later info takes
precedence
over the earlier info.
2. Operation-specific info overrides generic transport info,
and
this rule takes precedence over rule 1.
Umit: What is the value of allowing a list of bindings?
Marsh: It allows you to have little chunks of bindings and combine
them.
JeffM: This looks like it's adding a lot of error-prone complexity.
Sanjiva: Grid people make a grid service port type. It would be useful
for them to define generic binding info, and then make it more
specific.
SteveG: How will I know why this combination of bindings that works on
one vendor's software, craps out on another's? How do I know
whether a particular piece of binding info may violate the ___
rule? I have a NotificationBroker that inherits from
GridService
interface. How do I specify bindingA info that applies to all
GridService's, and also supply bindingB for NotificationBroker
that supplements the bindingA info?
Youenn: We could add instead add an @extends="qname" attribute to
<binding>.
SteveG: But interface inheritance takes a list of qnames.
Tom: This is going to far. A little cut and paste is okay.
SteveG: But cut and paste isn't scalable when you have millions of
these.
JefferyS: Some use cases are sophisticated; some are simple and want an
unsophisticated design. Adding porttype inheritance was a big
jump in the sophistication of WSDL. Now we're contemplating
another jump.
SteveG: Where does the sophistication of my use case start causing you
to lurch?
Amy: When you talk about overriding the binding info.
Sanjiva: If there's a way to make it work for the more advanced case,
without adding complexity to the simple case, then I'm okay
with
adding a mechanism to permit the advanced case.
Tom: The simpler the better.
Igor: Tool vendors are a minimal concern, because it's done once.
Amy: My argument is that the likelihood of valid differences of
interpretation among implementations grows with this
complexity.
Umit: If there's no workaround, then the complex use case is more
compelling.
(JefferyS made a procedural request that we not base our argument on the
fact that we've made a similar previous decision.)
Do we want WSDL to support Steve's use case of refinable bindings?
Use case uc1: In the case of interface inheritance, i want to use
separate
binding elements to describe operation-specific bindings for each
interface
in the inheritance graph.
Straw poll: Do we wish to support uc1?
In favor: 8
Against: 4
JeffM: Why are we adding requirements when we adopted a requirements
document a long time ago? I'm concerned that we might keep
trying to add more requirements.
(Discussion of procedural question about whether we should add this to
the
requirements doc.)
JeffM: I was indifferent to this case, but if we go further I'm
going
to object. This is why I want it in the requirements doc.
Tom: I don't have specific tech objections to this use case, but
the
meta issue. I am unhappy that we are adopting multiple
things
that will make me unhappy at the end.
DBooth: The individual additions may be okay, but the aggregate is
unacceptable complexity.
JeffM: This is a bunch of local optimizations but not globally
optimal.
Sanjiva: I've argued against interface inheritance, but what we added
is
not really inheritance even. It's union, which isn't that
hard.
But here we're talking about composition of bindings. I
think
we should either solve the whole thing that includes
overriding
of binding info, or none.
JeffS: I hoped we could make this decision independent of others.
Roberto: Do the elements have to be consistent about binding type
(SOAP,
HTTP, etc.)?
SteveG: Don't know.
(Question about multiple addresses in an endpoint)
SteveG: I would imaging a multiple address requirement would come in
on
the third layer of use case sophistication.
Amy: What does it mean if I combine SOAP-HTTP binding with an HTTP
binding?
Glen: Same problem as conflicting extensions. We can't define.
(JefferyS added the earlier requirements to our requirements doc.)
"Homogeneous bindings": Bindings of the same type.
SteveG: The heart of my issue is knowing how binding info can be
combined.
(Procedural discussion of how to proceed)
Marsh: Who cannot live with Sanjiva's second part:
[[
Allow <endpoint> to point to bindings or inline binding:
<service interface="qname">
<endpoint name="ncname"
[bindings="list-of-bindings"]
inlined-bindings
address-binding
</endpoint>
</service>
]]
Marsh: Who cannot live with us supporting uc1?
(Roberto and Tom cannot.)
Marsh: Who cannot live with the status quo, which includes:
[[
Make @interface optional in <binding> to make binding more
reusable:
<binding name="ncname" [interface="qname"]>
binding details
<operation name="qname">...</operation>
</binding>
]]
(SteveG cannot.)
-------------------------------------------------------
15:00 Break
-------------------------------------------------------
Glen: The real problem: When you compose things, there needs
to be some kind of rule to prevent different binding types
from clashing. But we realized that's a different problem,
because we have that problem now. You could put
conflicting binding types in one element today. So we
should separate that issue from the question of binding
inheritance.
Umit: But can you override binding info today?
DBooth: It depends on the binding specs.
Glen writes:
[[
<wsdl:binding>
<soap:stuff> ...
<operation name="op">
...
</operation>
<jms:stuff />
</wsdl:binding>
<wsdl:binding extends="foo">
<soap>
</binding>
<binding name="foo">
<jms:foo>
</binding>
]]
Amy: If you are including them from different files, the problem
is less visible. My primary opposition is allowing the
override to take place.
Marsh: Does this address Tom or Roberto's objection?
Roberto: Not entirely. If endpoint has one binding which may inherit,
then I'd be fine if the rules allow for inclusion of other
bindings. But the requirement should still say that the
bindings must be compatible. The rules for inclusion are up
to the binding.
Glen: Single binding with multiple binding extensions.
Roberto: Need to be clear about which set of rules applies.
JefferyS: Interactions of binding extensions I believe are out of scope.
If two are inconflict, you'll have to look at the specs of
those binding extensions to resolve the conflict.
Glen: I think the data model we have is:
[[
binding1
<qname> / property
<qname> / property
operation
<qname> / property
<qname> / property
operation
<qname>
<qname>
binding1
<qname> / property
<qname> / property
operation
<qname> / property
<qname> / property
]]
There isn't a huge difference between how you would compose
these in a single binding, and composing separate things.
JefferyS: If we add binding inheritance we'll have to say something
about how they are combined.
Glen: SOAP 1.2 says that the composition of extensions is not
defined by SOAP 1.2. You can already use include mechanisms
to pull stuff in from other files.
DBooth: Then why have this inheritance?
SteveG: But there is inconsistent support of xinclude.
JefferyS: A first class way to reference a construct is that the binding
fragment would have a name. An xinclude approach gives you
the
content, though you might not have a name. So you could name
some XML expressions for some binding fragments.
Glen: So a problem is that we don't mandate xinclude.
Marsh: But we already mandate external entities, which could also be
used.
JefferyS: So if there is a viable workaround, then we can ack the use
case without addressing it in the spec.
Glen: I'd like to raise an issue about being more explicit about
composibility of extensions.
Proposed resolution: We ack the use case uc1 without addressing it in
the
spec, because there is a viable solution with external entity, although
you wouldn't get binding operation overloading.
(more discussion without resolving)
Glen: Proposal g1: I propose a mostly lexical include, triggered by
an attribute called @include, which takes a list of qnames of
bindings. Component properties in the content model would be
properly merged.
Amy: I think this would be opening a can of worms.
Sanjiva: I think the external entity solution works but it's a hack.
The other would be cleaner.
DBooth: It seems silly to add this feature for a lexical include that
we already have in other ways.
Roberto: But what happens to the interface attribute?
Glen: It would have to be the same or a subclass.
Marsh: Glen's proposal would also enforce the inheritance between the
interfaces, whereas the xinclude or external entity solution
wouldn't.
Straw poll on g1:
In favor: 4
Opposed: 8
Proposed resolution: We ack the use case uc1 without addressing it in
the
spec, because there is a viable solution with external entity, although
you wouldn't get binding operation overloading.
Straw poll on proposed resolution:
In favor: 10
Opposed: 0
(Proposed resolution accepted)
RESOLVED: Eliminate requirement R133.
(break)
Marsh: Should we consider, in the endpoint, allowing the user to
either inline a single binding or specify a @binding
attribute?
Amy: When you inline it you are saying "don't reuse it".
SteveG: It adds complication by making two places to look.
JefferyS: Could be consistent by either making everything inlined or
named.
Tom: Two ways to do it adds complexity.
Straw poll: Should we, in the endpoint, allowing the user to either
inline a single binding or reference a binding via a @binding attribute?
Favor: 3
Against: 7
Group has consensus
----------------------------------------------
Topic: SOAP Binding
(Group continues discussing Sanjiva's proposal:
http://www.w3.org/2002/ws/desc/3/07/SanjivaBindings1_clean.htm
or original PowerPoint:
http://www.w3.org/2002/ws/desc/3/07/SanjivaBindings1.ppt )
Proposal: We adopt the following changes:
[[
Define default SOAP binding rules:
- @body goes into <soap:Body>
- Each of @headers goes into <soap:Header>
Drop <wsoap:body>, <wsoap:fault>
Change <wsoap:header>: add new header or add @role/@mustUnderstand
- Drop @type, @namespace, @localname, @encodingStyle
]]
Group agrees.
Proposal to adopt:
[[
- Add @mustUnderstand (if it isn't there already) and @role.
The values of these attributes must be consistent with the constraints
in the schema.
]]
Group agrees.
We'll view these as a single issue and defer:
[[
Drop <soap:binding>: drop @protocol
Change <soap:address>: add @protocol
]]
These will be included in issue #2:
[[
Define new binding element for default rule for
wsoap:operation/@soapActionURI
- Proposal = interfaceTNS#operation-name
]]
Decided to add a new issue #84 on whether to retain <wsoap:headerFault>.
Sanjiva presented:
[[
For @encodingStyle=rpc case
- If types are all simple, then can do HTTP GET/POST
binding for content-type=form-url-encoded
- URL rewriteing, POST body, ...
For other cases:
- Natural text/xml binding with input/@body as
input payload and output/@body as output payload
]]
Group discussed. Decided to add a new issue #85 to fix HTTP binding,
since it is now broken.
ACTION: Philippe to make a proposal for fixing the HTTP binding.
-------------------------------------------------------
17:30 Adjourn
-------------------------------------------------------
Received on Wednesday, 6 August 2003 13:15:48 UTC