- 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