Minutes, 31 July 2003 FTF Raleigh

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 

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
----------------------   ----------------------
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 

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

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
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
apply to an operation of the same QName in potentially different

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
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
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. 


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:
or original PowerPoint:

Make @interface optional in <binding> to make binding more reusable:
<binding name="ncname" [interface="qname"]>
  binding details
  <operation name="qname">...</operation>

Allow <endpoint> to point to bindings or inline binding:
<service interface="qname">
  <endpoint name="ncname"

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
             over the earlier info.
          2. Operation-specific info overrides generic transport info,
             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
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

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
          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 
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
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
          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
Umit:     If there's no workaround, then the complex use case is more 

(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
binding elements to describe operation-specific bindings for each
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
requirements doc.)

JeffM:     I was indifferent to this case, but if we go further I'm
           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
           meta issue.  I am unhappy that we are adopting multiple
           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
Sanjiva:   I've argued against interface inheritance, but what we added
           not really inheritance even.  It's union, which isn't that
           But here we're talking about composition of bindings.  I
           we should either solve the whole thing that includes
           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
           HTTP, etc.)?
SteveG:    Don't know.  

(Question about multiple addresses in an endpoint)

SteveG:    I would imaging a multiple address requirement would come in
           the third layer of use case sophistication.
Amy:       What does it mean if I combine SOAP-HTTP binding with an HTTP

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

(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"

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
	<binding name="ncname" [interface="qname"]>
	  binding details
	  <operation name="qname">...</operation>
(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 
Umit:      But can you override binding info today?
DBooth:    It depends on the binding specs.
Glen writes:
	  <soap:stuff> ...
	  <operation name="op">
	  <jms:stuff />
	<wsdl:binding extends="foo">
	<binding name="foo">

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:
	  <qname> / property
	  <qname> / property
	    <qname> / property
	    <qname> / property
	  <qname> / property
	  <qname> / property
	    <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
          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 
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
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 

Straw poll on g1: 
In favor: 4
Opposed: 8

Proposed resolution: We ack the use case uc1 without addressing it in
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.


Marsh:    Should we consider, in the endpoint, allowing the user to 
          either inline a single binding or specify a @binding
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 
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:
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 
  - 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