- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: 2004年5月24日 21:48:28 -0700
- To: <www-ws-desc@w3.org>
- Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA203B6C8AF@RED-MSG-30.redmond.corp.microsoft.com>
Web Service Description Group Minutes, FTF meeting 19 May 2004 New York City, hosted by IBM. ------------------------------------------------------- Wednesday 19 May ------------------------------------------------------- Present: David Booth W3C Allen Brookes Rogue Wave Software Roberto Chinnici Sun Microsystems Glen Daniels Sonic Software Paul Downey British Telecommunications Youenn Fablet Canon Hugo Haas W3C Amelia Lewis TIBCO Jonathan Marsh Chair (Microsoft) Jeff Mischkinsky Oracle David Orchard BEA Systems Bijan Parsia University of Maryland MIND Lab Arthur Ryman IBM Jerry Thrasher Lexmark Asir Vedamuthu webMethods Sanjiva Weerawarana IBM Umit Yalcinalp Oracle Prasad Yendluri webMethods, Inc. Phone (part of the day): Ugo Corda SeeBeyond Yaron Goland BEA Systems Jean-Jacques Moreau Canon William Vambenepe Hewlett-Packard Regrets: Tom Jordahl Macromedia Hao He Thomson Kevin Canyang Liu SAP Observers: Marc Goodner SAP scribe: Jeff ------------------------------------------------------- 09:00 Introductions and logistics - Assignment of scribes Jeff Mischkinsky (1), Roberto Chinnici (2), Amy Lewis (3), Youenn Fablet (4), Sanjiva Weerawarana (5) - Agenda bashing Part 1 and 2 -- we never quite hit zero bug bounce, but on hold for the moment -- about 10 issues -- probably deal with in telecons Part 3 - get to zero issues - or at least plan for each issue The usual getting the network going. Random discussion about schedules, magical person month myths, etc. Tentative last call june/july. Revisit later in meeting. ------------------------------------------------------- 09:15 Media Type Description Note [2] - review status, open issues [3, 4], content - raise issues, next steps - Goal is to approve pub as Working Draft [2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-t ypes.html?rev=1.4&content-type=text/html;%20charset=iso-8859-1 [3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x161 [4] http://www.w3.org/2002/ws/desc/2/06/issues.html#x162 Umit presented the current Media Type proposal. Q: What happens when there is a mismatch between expected and mismatch? Declare a ws that accepts a range of media types, but the actual message sends a media type out of the range. Umit: assumption is that this group may need to define faults for error codes. Discussion about whether we need to do this. This can't be handled via schema validation. Issues: mt1. possible error conditions: mismatch between value of media type attribute and pattern -- says nothing about the data mt2. possible error conditions: mismatch between the media type attribute and the actual data mt3. Is acceptMediaType the right name for the attribute. valid?, expected? permitted? emitted? (suggestions) mt4. where should appInfo go -- on the type and/or element? mt5. remove or describe fully multipart and message -- i.e. the composite types mt6. acceptedMediaType should be able to be a list mt7. Consider changing name from mediaType to contentType mt8. Would like more examples: e.g using a static type -- i'm always going to use an image/jpeg. What would that look like? mt9. Explain why this proposal is limited to base64encoded? mt10. Explain why */* AND absence means this is opaque application data (i.e. application/octet-stream. mt11. Pattern includes use of priorty -- either explain relationship or get rid of mt12. How do annotations show up in component model? (currently limited to a "binary information element") Jonathan raised question of whether this proposal could be more generally applied to base64 attributes. Consensus seemed to be that's going too far our purposes. Question as to timing. David observed that this is de-coupled from the last call, and that this will be note. We do however have to coordinate with XMLP. Issue mt5 Proposal: remove composite types *** UNAN accepted Issue mt3 Proposal: rename acceptMediaType to expectedMediaType *** UNAN accepted Issue mt6 Proposal: make expectedMediaType a list *** UNAN accepted [ACTION: Media type editors to implement these resolutions prior to publication.] Plan -- umit to communicate to XMLP the above issues and resolutions. [ACTION: Umit to communicate to XMLP the above issues and resolutions.] Take up when to publish thursday or friday. 10:45 Break ---------------------------------------- scribe: Roberto ------------------------------------------------------- 11:00 Review of Part 3 We took 30 minutes to individually review the latest part 3 draft. The review identified the following issues: [179] put and delete need to be added (Hugo) [180] inconsistent propagation of soap:header/module and F&P (Roberto) [181] bind to other protocols (JJM) [182] defaultMEP inheritance - syntax or model? (Marsh) [183] wsoap prefix (Sanjiva) [184] MTOM serialization into SOAP body (Ugo) [185] eliminate wsoap:header (Sanjiva) [186] interaction between wsoap:header and wsoap:module (Umit) [187] interaction between MEPdefault and webMethodDefault (Youenn) [188] wsoap:address vs http:address (DaveO) [189] binding message content to URI (DaveO) [190] layering of SOAP webmethod on top of HTTP binding (DaveO) [191] relationship between SOAP MEPs and WSDL MEPs (Hugo) [192] 2.4.1 "increasing specificity" -> "decreasing..." (Amy) [193] header declaration at different levels (Youenn) [194] why interleave wsdl: and wsoap: elements? (Glen) [195] property value merging (DaveO) [196] f&p/module at operation level vs input/output message level (Asir) ------------------------------------------------------- 11:30 Issue 72: MTOM support [5] - Jean-Jacques' proposal for @mediaType, @reinsert [6] [5] http://www.w3.org/2002/ws/desc/2/06/issues.html#x72 [6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0295.html Marsh: Is "MTOM serialization into SOAP body (Ugo)" all that is left to do? What do we need to do to indicate that a client needs to use MTOM serialization? Glen: Isn't there a header already defined in MTOM? First of all, the media type will be different, and that's going to appear in WSDL as a flag. Marsh: What should the flag look like? Glen: Many ways to do it: an extension, a property, a full new set of bindings. Amy: What we do should be reusable; e.g. an extensibility attribute of type anyURI to indicate the serialization. Glen: Why not use a feature? Amy: It's overkill. Glen: No, it's the same amount of work. Marsh: Then what are the conformance requirements? the expectations may be different for features and attributes. Amy: You can mark the feature as required. Marsh: As a user, I'd like to find an appendix in the MTOM/SOAP specs that tells me how to enable it in a description. Glen: I know that MTOM is a feature, but we should confirm that MTOM+XOP is a feature. Then all it takes to enable SwA is to write a wrapper feature for it (but that's out of scope for the WG). MTOM defines the "HTTP transmission optimization" feature. RESOLUTION: We'd like to describe MTOM availability using our feature mechanism and we need to coordinate with the XMLP working group. RESOLUTION: Close issue 72. ACTION: Glen to write an example of expressing MTOM in WSDL using f&p and send it to the XMLP WG. ACTION: Editors to include in the primer an example that uses MTOM. ------------------------------------------------------- 11:45 Issue 96: Intermediaries [7] - Jean-Jacques' proposal for @mustUnderstnad, @relay [6] [7] http://www.w3.org/2002/ws/desc/2/06/issues.html#x96 Glen: Certain attributes on wsoap:header are only useful when describing intermediaries e.g. @mustUnderstand on a header addressed to a notarization intermediary, because I want to make sure that if there is such an intermediary it will do the right thing. Amy: Don't you need these attributes for modules too? Glen: Not necessarily. Amy: It comes back to the "let's get rid of wsoap:header" discussion. Are we going to invest in wsoap:header? Marsh: If we remove wsoap:header, do we remove the ability to describe intermediaries altogether? Glen: It'd be harder to do the same thing with modules, it would affect the module specification. Amy: Your module specification should take that into account already if there are multiple roles. Marsh: If we remove wsoap:header, isn't someone going to write the add-a-header module? DaveO: Yaron did, it's ADD. [discussion on how it could be done with wsoap:module only, but that seems to require nesting of properties under modules.] Glen: A module that uses five headers would define five independent mustUnderstand properties, if needed. Umit: If the tweakability is not defined in the module I want to use, I have to define my own module. But today with soap:header it's a lot simpler. Glen: Example of two related headers, "challenge" and "response"; in general, determining the tweakability points is hard. Marsh: And for a user it would be even harder. Amy: Strawman: <wsoap:module mustUnderstand="list of QName" role="list of pair {QName, QName}"/> Glen/Youenn: Lists are not good enough, the rules are too complex. Marsh: Couldn't we address the simple cases and leave the hard ones to the modules? Amy: What is the common case? Glen: For WSRM, the common case is the complicated one; for WSS, the common case is simple. Amy: Can we expose a simple mechanism that works in common cases? Glen: In the simple case, wsoap:header is not bad. Or use an anonymous module. Amy: But modules don't work for HTTP, only SOAP. Glen: It's important to have wsoap:module, because they are in the SOAP 1.2 spec; there are two other issues: is it important to be able to specify generically headers and set attributes on them? and if we do, can we tweak the module syntax to do it or should we stick to wsoap:header? Umit: But aren't we making migration harder? Marsh: If I want to add a new header, I can with wsoap:header without forcing me to update my processor (to understand a new module and process it correctly). Ugo: If there are multiple intermediaries, is there only one WSDL file or several ones? Glen: The endpoint in the WSDL file is what the client talks to; that WSDL may contain knowledge about some intermediaries. Amy: But if it has a description, it's a service, it cannot be "just" an intermediary. DaveO: Analogy with HTTP; in WSDL, interfaces are not constrained, so we cannot constrain intermediaries and we should allow all of them to be described. Glen: Distinction based on whether the client is aware of an intermediary. DaveO: HTTP makes that distinction too (gateway and proxy, perhaps?) Marsh: Are there any use cases we want to rule out? Ugo: You are focusing on the client side, the traditional use of WSDL. Amy: Disagrees, we're focusing on the contract for a service. 12:30 Lunch ---------------------------------------- 13:30 Intermediaries (cont.) back form lunch, discussion continues Enumerating the possibilities: 1) keep wsoap:header and add @mustUnderstand, @role, @relay, @reinsert 2) add @mustUnderstand and @role to wsoap:module (for simple cases) Amended the wsoap:module proposal to rename @mustUnderstand -> @setMustUnderstand and change @role's type to be a list of {QName, uri} Glen: Anonymous module proposal amounts to giving a choice between using @uri or @setMustUnderstand/@role, i.e. if @uri is omitted the module is anonymous and the other attributes must be present. Amy: Don't understand the direction this is going, prefer to use properties to do that. Marsh/DaveO: Essentially ADD does the same thing in the abstract, and then it trickles down to the SOAP binding. Amy: Except that it'd have to be amended to make headers appear directly under soapenv:header. DBooth: what would Tom say? Roberto: wsoap:header is direct, understandable and it works, so let's just do that. Hugo: I like the first form, but maybe we don't have the tools to use it, and we should go with the second one. Asir: Likes both, would like wsoap:header to be under wsoap:module. Glen: There is an elephant in the room, i.e. that you need to understand the semantics to use headers effectively, the data definition alone is not enough. Marsh: (describes the case of application-specified data) Allen: Then we're saying in most cases we got just the illusion of simplicity. DBooth: Likes to use existing features, like f&p, to solve the problem, if possible. Cringes. Glen: Another proposal: come up with a convention for property names made available by default by every module to tweak flags on the headers (supported by those modules). Roberto: How is that simpler? Glen: Avoids additional syntax. Roberto: In the wsoap:header case, the syntax matches the concepts, so it's simple for users. Prasad: Without a module wrapper around a property, we preclude having different modules use the same header. Amy: +1 on Prasad's comment. Would like to get rid of one of the constructs, wsoap:module or wsoap:header. Glen: We need to keep both the simple and the complex cases in mind. Umit: The most general one is features. Glen: There is a reason for the existence of features, bindings, modules. XMLP wanted to enable naming the semantics that HTTP (say) provides natively in an abstract way, so that equivalent functionality could be provided via SOAP modules (in the SOAP world). An abstract feature is a kind of interface; a binding implements a feature. Modules bring multiple headers together and implement one or more features. Umit: Maybe then the features in WSDL are different from those in SOAP. Glen: No, at the abstract level there is no difference. Having separate bindings and modules in WSDL makes it easier to add the support for certain features to a binding, without requiring a new binding. Umit: We could add an attribute to a feature saying "use module foobar". Amy: Agrees with this direction. Glen: Disagrees. Marsh: As we keep talking about this, the scope of the conversation is widening more and more. DaveO: Question about the relationship between bindings/modules/ features/properties in SOAP and WSDL, can they be brought together? Glen: Features and modules are the same in WSDL and SOAP. DaveO: Are properties the same too? Glen: Yes. (drawing a diagram) a module implements zero or more features. The *specification* for a module will list the features it implements. DaveO: This apparent complexity is necessary because we have extensibility in terms of MEPs, protocols, etc.; if we had stuck to request-response HTTP, there wouldn't be a need for it. Another example is correlation between request and response, that (in general) needs to happen at the SOAP layer. So if the world agreed to use, say, WS-Addressing to do correlation, we wouldn't need a correlation feature. Glen: #1 yes, #2 no, because if you go there you violate all the assumptions that were made in creating web services. Marsh: We are back to redesigning SOAP now. Glen/Sanjiva: When you see wsoap:header, either your infrastructure recognized the QName there as, say, a security header (and then it's not going to change the application), or it does not, but then the application needs to know about it; the idea is that if anything can affect the application interface, it should be in the abstract. Marsh: Then you're saying it's either totally in the application or in the infrastructure. Paul: But the case of headers with a role attribute is different, because they go to an intermediary, not the application. Glen: Even if the header is destined to an intermediary, somebody has to put it in there. The ADD feature describes the data being passed in the abstract. Paul: I must be able to describe existing interactions that use wsoap:header. Roberto: If the application has to set properties somewhere, it doesn't make any difference if the WSDL used a wsoap:module or a wsoap:header. Umit: Are we back to the time when we had a headers="..." attribute on an input message? DaveO: The problem is that schema doesn't give us enough functionality to do what we want, hence the need for ADD. Sanjiva: The SOAP binding says that the contents of the body must be the element specified in the abstract. Youenn: If you define a headers attribute you encourage people to use it. Roberto: Not having the headers attribute makes the cost of creating new bindings lower (one less requirement to support). Marsh: Do we need to reopen the whole issue? Sanjiva: No, the current issue is only at the SOAP binding level. DaveO: We could define a soap module that allows inserting a header and make wsoap:header syntactic sugar for it. Glen: Pull out wsoap:header now and see if we need it. DaveO: Easier to take stuff out at last call than adding it in. Marsh: For the specification, the other way is better. Roberto: We need to cover both uses of soap:header in our spec: in the abstract, that's ADD, at the SOAP level it would be a standard module that can be used to insert a header. Paul: Agrees. Marsh: Anybody opposed to removing wsoap:header, with the understanding that we will define a module that allows headers to be inserted (perhaps using the ADD) no replies? Glen: Everyone needs to understand that by doing this we are pushing handling of role/mustUnderstand to module writers. Sanjiva: Isn't using role/mustUnderstand in ADD at the abstract level a SOAPism? Proposal: the ADD feature only declares the QName of the element; then the default binding rules for SOAP will make that into a header, without requiring a module; finally, mustUnderstand/role can become properties to be used in the SOAP binding. Glen: Friendly amendment: define a SOAP module anyway, don't default it. Roberto: Objects to removing soap:header unless we provide a standard way to insert headers at the binding level discussion... if the ADD and property merging issues are solved, then we can eliminate soap:header without losing functionality. RESOLUTION: Close 185 by removing soap:header RESOLUTION: Close 186 as obsolete ACTION: Editors to remove soap:header. Add issue 195 for property value merging; merge 193 and 195, since they are related. [Previously added. 193 closed later on.] 15:30 Break ---------------------------------------- 15:50 Discussion of Issues opened this morning scribe: Jeff ------------------------------------------------------- Issue 181: bind to other protocols (JJ) Editorial/descriptive glitch -- drop the word "only" from 2.2.2 SOAP Binding Component and describe what happens if a different uri is used, but it MUST be compatible with wsdl soap binding Accepted -- UNAN RESOLUTION: Close issue 181 by dropping the word "only" from 2.2.2 SOAP Binding Component and describe what happens if a different uri (which must be compatible with the wsdl soap binding) is used. ACTION: Editors to fix 2.2.2 to allow other protocols. ------------------------------------------------------- Issue 196: Module operation at operation level vs input/output level RESOLUTION: no objection to CLOSE NO CHANGE ------------------------------------------------------- Issue 180 and 193 -- related For a given interaction, a module is either present/not present and required/not-required. Question is how to merge when the "tree" is collapsed. Closer to leaf overrides, with exception of required-ness. Amy wants to be able to turn off required-ness and availability, without pushing all the info "down" the tree, which the current rule requires (so to speak :-). Mechanism -- default-<attr>value applies at a particular level and <attr>-value for particular instances at a level. How are modules connected to interface? Not directly. If a feature is required in the abstract feature, then a module which implements the feature is not required. [Conversation is more complicated than can be captured by the poor scribe in a linear fashion typing at finite speed.] Sanjiva -- can have rules for how modules are combined which are different from combining features and properties. Stwapoll: Who believes it is important to be able to shut off required and availability 4 - yes 8- no Amy registers objection that this is ugliness and treating req/avail as special cases in this way will be confusing. Sanjiva Proposal: a module has 2 attr, a uri and req flag and if have more than one module with the sam uri in scope then resolve by going up the tree - msg->op->interface. (nearest enclosing scope wins -- i.e. std lexical scoping rules in block structured programming languages). Glen observes that this is different from what's in features and they should be the same. Proposes that if we adopt sanjiva's proposal, then we should also change the rules for features. EG: soap module is required at binding level -- then within operation i can turn that off. is this ok? Q: a. define a color=red at interface b. define color=red at msg level 4 times Is there a difference in semantics? There could be a difference in the semantics if the module takes into account at what level it appears. Not clear that the spec accurately says this. (editors will check) RESOLUTION: Both Proposals are accepted UNAN ACTION: Editors to make propogation of modules and f&p use the nearing enclosing scope. NEW ISSUE: 197 Don't override interface features that are required in binding (umit) ------------------------------------------------------- Issue 182 - defaultMEP inheritance-syntax or model? Is this pure syntax or is there a semantic implication? Should be pure syntax, component model mapping is wrong in spec. Also true for webMethodDefault and defaultMethod in HTTP binding. RESOLUTION: Change component model to remove default* properties, use mapping from syntax instead. ACTION: Editors to fix component model to remove default* properties, use mapping from syntax instead. 18:00 Adjourn
Received on Tuesday, 25 May 2004 01:03:55 UTC