- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 4 Feb 2004 09:49:30 -0800
- To: <www-ws-desc@w3.org>
- Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2027A6BCB@RED-MSG-30.redmond.corp.microsoft.com>
Web Service Description Group Minutes, FTF meeting 29 Jan 2004 Bedford, hosted by Sonic. irc: http://www.w3.org/2004/01/29-ws-desc-irc Present: David Booth W3C Michael Champion SOftware AG Roberto Chinnici Sun Microsystems Glen Daniels Sonic Software Paul Downey British Telecommunications Tom Jordahl Macromedia Philippe Le H馮aret W3C Jonathan Marsh Chair (Microsoft) Jeff Mischkinsky Oracle David Orchard BEA Systems Bijan Parsia University of Maryland MIND Lab Arthur Ryman IBM Adi Sakala IONA Technologies Jerry Thrasher Lexmark William Vambenepe Hewlett-Packard Umit Yalcinalp Oracle Observers: Hugo Haas W3C Phone: Allen Brookes Rogue Wave Software Amelia Lewis TIBCO Kevin Canyang Liu SAP Yaron Goland BEA Systems Jean-Jacques Moreau Canon Sanjiva Weerawarana IBM Prasad Yendluri webMethods, Inc. Regrets: Youenn Fablet Canon Jacek Kopecky Systinet Ingo Melzer DaimlerChrysler Jeffrey Schlimmer Microsoft Igor Sedukhin Computer Associates scribe: Arthur Ryman ------------------------------------------------------- Thursday 29 January ------------------------------------------------------- 09:00 Attribute styles "at risk?" - Word from GGF that they don't want attribute styles [10]. - Issue 103: Proposal for combining the two attribute operation styles to one [11, 12] [10] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0086.html [11] http://tinyurl.com/ysgl#x103 [12] http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0164.html Jonathan: Are there any objections to dropping them? Umit: Yes. They are useful outside of GGF requirements, so why remove them? They are a good example of how to extend styles. Glen: Could they be put in primer? Jonathan: Sounds too advanced for primer. Glen: Should not be in spec. Arthur: IBM position is to support GGF spec WS-ResourceProperties, etc., so there is no need for this function in the WSDL spec. Jonathan: There is significant cost in leaving it in our spec. Umit: We still need an example of using styles. Philippe: HTTP style is an example. Jeff: The argument that another group (GGF) is doing it isn't valid. Why did GGF duplicate our work? Bijan: Not a valid argument since GGF was the group that proposed it. Jeff: Steve Teucke advised us that GGF was not interested in the "weakened" support this group was adding and that they were proceeding on their own. Dave: The GGF did a lot of work that was more than this group did, i.e. this group only did a subset. Jonathan: Umit, do you still disagree to pulling it out? Umit: OK, I agree to pull it. Bijan: What about a Note? Jonathan: That can happen at any time independently of the WG. Jonathan: Resolved to pull attribute styles. Jonathan: Issue 103 is now irrelevant so I propose to close it. RESOLUTION: Remove attribute styles. RESOLUTION: Close issue 103 as irrelevant since styles are removed. ------------------------------------------------------- 09:30 Features and properties "at risk?" - WSChor statement [13] - Issue 108: properties and schema languages other than XSD [14, 15] If properties remain, we need to discuss requirements for a solution to this issue and recruit a champion. [13] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0066.html [14] http://tinyurl.com/ysgl#x108 [15] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0006.html Jonathan: Support for F&P seems to be dropping. Can we reaffirm our desire to keep F&P? Also need to discuss message from WS-Chor about F&P. Glen: WS-Chor needs F&P so ensure compatibility betweens multiple nodes in a business process. Jonathan: Aren't F&P isomorphic to extension elements? Glen: Not exactly. Properties augment nodes with additional information. Jeff: WSDL can be used to declare properites used in choreography. Why do we continually discuss removing F&P? Jonathan: There is still lack of understanding on the text in the spec. Need more clarification in the spec. Jeff: Compositor proposal should clarify F&P. Umit: Compositors are used in useful examples. Jonathan: Are compositors necessary for F&P, i.e. accept both or neither? Glen: Compositors are great. Very useful. Dave: Similar constructs are used in other languages. Glen: e.g. how to determine which operation is invoke, e.g. SOAPAction, QName of Body element Paul: The key use of properties is that provide a policy framework Glen: True, but F&P goes beyond policy frameworks since it also covers parts of the runtime. Paul: There are other ways to add metadata, but the F&P approach is attractive Philippe: Compositors are not part of the WSDL requirements, so you are proposing to add this Sanjiva: Where else are we using Features? Glen: We are planning to add the Operation Name feature. e.g. if two or more operations produce identical messages, how do you differentiate them and identify the operation. Jonathan: Umit, please present your proposal. [umit: the presentation is in http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/att-0189/CompositorF2FPresentationForWSDL.pdf] Umit presenting: Compositors for WSDL 2.0 Sanjiva: why do we need compositors when we have had trouble finding use cases? Umit: Compositors allow F&P to be applied to more situations and therefore more useful. e.g. the Choice semantics cannot be otherwise expressed Glen: This allows richer semantics on how properties are combined Roberto: We found we needed compositors to apply F&P to real situations Bijan: Are compositions names (e.g. with a URI)? Umit: Not at present, but we could do that. Sanjiva: In the Pseudo-Syntax, but does a specific binding, i.e. soap, show up? Glen: That was a common case but we could replace the specific soap module element with a general extensibility element. An example of using soap modules would to say that several security modules but only one at a time. [TomJ: You can currently get all and zero-or-more with the current required syntax. Compositors are adding one or more and choice.] [jjm: ... and also nesting.] Glen: In some cases choice can be expressed with appropriate designed properties Umit: Compositors give you the power to compose arbitrarily designed properites and features Sanjiva: Is the uri on the compositor element an extension point? If not why not use four elements with better names, e.g. <all>, <choice>, <zero-or-more>, <one-or-more> Umit: Having the four elements makes the schema more complicated Sanjiva: Is the uri extensible? Umit: Yes, it is extensible. Tom: the example on Slide 12, Feature Configuration using one-or-more, make what was once simple very complicated Glen: the example may not be good. A better example is to specify the type of authentication required by an operation, e.g. X.509, Basic Authentication Tom: Example on slide 13 looks overly complex. why wrap a compositor around a single property Umit: Because in general there can be more than one feature Tom: There is far too much complexity in compositors for them to be easily implemented on small devices Roberto: Compositors allow the composition of indepently developed features. Bijan: Compositors are very expressive, they are not primarily for compensating for poorly designed feaures [end of presentation] 10:40 Break 11:05 Features and properties (cont.) Glen: We should be done with discussing about dropping F&P since we have gotten support in the past Jonathan: There was dissent at the last F2F about F&P [alewis: Doesn't that imply that it needs to be clarified, not dropped?] Jeff: While it's in the spec it is valid for us to work on it, e.g. the compositor proposal Glen: F&P is useful on its own as is. Compositors make it even more useful. [jjm: R116: The description language MUST allow describing abstract policies required or offered by Services. "The description language MUST allow describing which SOAP features are offered by or required by an Operation or a Service."] jjm: R116 says we should support abstract policies, so we have a requirement on the books. Dave: Compositors are directly coupled to F&P. I am concerned that we may need even more technology to make F&P real. WSDL 2.0 needs to focus on other areas first, e.g. bindings, meps. [alewis: horsefeathers] Dave: F&P makes WSDL 2.0 too complex and diverts attention from the core problems. BEA position is that we should be addressing the other areas to complete WSDL 2.0. [alewis: TIBCO completely backs Glen/Sonic's statement on the inclusion of features and properties] [jjm: +1 to Glen and Amy] Glen: Disagree that F&P is not core and too complex [TomJ: I agree with Dave O's statement that there are much better uses of our time.] [sanjiva: +1 to TomJ :)] [jeffm: -1 to sanjiva and tomj :-)] [jjm: ;-)] Glen: There are other solutions, like WS-Policy, and if its authors contributed it to WSDL then we would be done Arthur: Since the requirement specifically addresses SOAP, why not put this in the SOAP binding and perhaps arrive at a simpler design? Glen: The design would not be simpler and leaving it in the core language makes it available for broader usage Sanjiva: Isn't the F&P information more useful outside the scope of WSDL? i.e. F&P is metadata which may be useful in other contexts. Amy: The scope of this WG is WSDL and until the other solutions (WS-Policy) are offered RF, then we are obligated to work on a solution Jeff: Compositors are basic computer science and needed to express real world situations so it should be in the foundation. There is no universally useable spec so this WG should provide a solution. Dave: There is a lot of overlap between F&P and WS-Policy and we are asserting that if WSDL provides this function then vendors will implement it. I challenge that assumption and feel that F&P will put WSDL 2.0 at risk. There is not a consensus that adding F&P is the correct thing to do. e.g. it took a very long time to develop WS-Policy and the work is ongoing so doing a similar job here will also take a long time [alewis: It was accepted into the specification at the March 2003 face to face, after about six months of task force work.] Glen: We have already done a lot of work on F&P so the work that exists already helps solve the requirement. The mission of this WG is to define metadata to describe Web services and we need to be able to describe arbitrary extensions, this is a major contribution of WSDL 2.0 Sanjiva: It seems that a major motivator for F&P is that WS-Policy is not available in RF terms [jeffm: WS-Policy is not available under any terms] Sanjiva: We have just requested a schedule extension and it is likely that WS-Policy will be refined in that time frame and be made more widely available [sanjiva: hahahahaha ;-)] Amy: Point of Order: Should discussion of WS-Policy be ruled out of order since it is not available on W3C terms. And should representatives of those companies recuse themselves from discussion? Philippe: The IP issues are not a concern. Also I will [not] support a further schedule extension. [alewis: ARyman: based on the value of licensing revenues to the companies represented.] [jeffm: DaveO has claimed that there has been lots of work on the WS-Policy has been occurring. That is certainly not avalable to anyone but the spec authors. I'm not saying it should be, anymore than any internal Oracle product specs are available to the public.] [jjm: +1 to sanjiva on this point!] Paul: Interoperability is a major requirement of Web services so we need to have an interoperable way of expressing F&P and Policy info. [sanjiva: Hypothetical question to Glen: If WS-Policy were submitted to an alternate standards body, say OASIS, would you want to stop the f&p work here or still continue it?] [DaveO: Jeff, I'm saying that work has been ongoing. So adding the roughly equivalent stuff to WSDL will add the same kind of schedule. ] jjm: This is the fourth time so I wonder why the requirement has not created an issue before. [alewis: It's already been worked on, Dave. Since March 2003, when it was accepted, and approximately six months before in the task force.] [jeffm: But we are not proposing adding roughly equivalent stuff -- unless of course you guys in the smoke-filled room :-) have performed some drastic surgery] jjm: We do have a schedule constraint. The bulk of the proposal could be in the spec by next week. [jeffm: If we were going to boil the policy ocean you might be right, but we're not] [sanjiva: Response to JJM: The requirements have been there but I personally felt we had met them by having F&P. This new compositor stuff didn't come to existence until the last month (or was not surfaced until this week or so). So I find it hard to accept that this stuff is designed to satisfy that requirement.] Umit: I agree with jjm. Priority is in the eye of the beholder. Dave suggests that work is continuing on WS-Policy and that we should not discuss it, but we have not had access to that work. Glen: In reply to Sanjiva, I feel strongly that F&P should be core to WSDL even if WS-Policy was RF. [sanjiva: Reponse to Glen: So you are saying that no matter what we would ignore WS-Policy and put similar function here? (Clearly the current published policy spec and this work does overlap.)] [jjm: jjm also said requirements about features and policies have been sitting quietly for 2 years (almost), without having been objected. Also, if need to cut work, could stop other items instead.] [GlenD: Not really, Sanjiva. I'm saying that IF the policy work was contributed to this group, that would be fine, potentially with some work.] Jeff: There is other work going on (OASIS XACML). The work on F&P has broader applicability. The OASIS and WS-Policy work is more aimed at enterprise applications. [sanjiva: Then what Glen? I don't understand your position .. its "core" to WSDL, but if its in OASIS you wouldn't stop it? ] [GlenD: But the functionality should be IN wsdl.] [sanjiva: So its either WSDL WG or nothing? OK now I understand your position.] [GlenD: It's like saying "wsdl shouldn't do bindings". It's core, imho] [sanjiva: No is there an alternate binding thing?] [alewis: +1 to jeff] Jeff: I also feel it is disingenuous that companies that have product plans based on competing specifications are blocking the work of this group. Tom: My company has no plans to develop competing specs and I agree with Dave that this will take a long time. Bijan: We have a requirement to support SOAP and there is interest from WS-Choreography. [TomJ: But schedule isn't my primary objection, unnecessary feature creep and complexity are my main problems] Jonathan: We can meet the SOAP requirement without a generalized WSDL language feature, i.e. adding it to the SOAP binding. The meets minimum solution does not require a general mechanism. Glen: Disagree. We need to support the SOAP extension mechanism. Dave: This is the issue of what is in scope. I would like to consider what is the minimum we need for success. Where do we draw the line? Dave: We learned a lot from WSDL 1.1, e.g. we feel the syntax is too hard. Or the 80% case should be the default and be easy to specify in WSDL. BEA position is that the 80% case needs to be very simple and we feel F&P is too complex and at present unbounded. [jjm: Not, not me, not the semantic web] [jjm: DaveO, I don't think it's fair to compare compositors to the semantic Web] Sanjiva: Concerning Jeff's comment that we are blocking progress, I disagree. WS-Policy is more flexible than the F&P proposal. [DaveO: jjm, my point was that I don't know how far the scope goes. I don't know where to stop on this work.] [sanjiva: IBM/MSFT statement of intent to give WS-Policy under RF Terms: http://news.com.com/2030-1069-5079712.html] Sanjiva: Concerning Glen's comment that F&P is core, I disagree. Things like security are about how a service is deployed. [jeffm: A statement of intent is worth the bits it is written on. It is always subject to modification based upon "changed business" conditions] Sanjiva: Concerning Amy's IP concern, there has been a statement intent to offer WS-Policy under RF terms. [jeffm: Could we please not reduce the arguments to dueling press releases] [GlenD: lol] [GlenD: (ok, not ol really)] [jjm: Sanjiva, would you (your company) consider submitting WS-Policy to W3C?] Umit: On lessons learned from WSDL 1.1, you cited the header problem which is an excellent example of F&P. [sanjiva: I would but I don't get paid enough to make those kinds of decisions. ] Umit: Other aspects, e.g. security and reliability are a big concern now. [pauld: Other forms of policy which could be considered as part of the interface: idempotency, safeness, etc] Jonathan: Vote? Glen: Not ready yet. Can we remove the F&P at risk issue? Jonathan: (with his Microsoft's hat) I'd like to get some experts at Microsoft before having a clear technical position. Jonathan: Let's close the compositor discussion for now and entertain further discussion later as well as counter-proposals. [plh-ws: Jonathan: objection to the status quo? i.e. keeping FnPs in the spec?] Jonathan: Since the requirement exists and there is WS-Chor interest and we should not be altering the a lot, I propose we leave F&P in and not label it at risk. Dave: I would like to label it at risk. BEA position is to remove it from spec. Sanjiva: IBM objects to it but agrees to leave it in. [Issue 108 deferred.] 12:10 Lunch scribe: Tom Jordahl ------------------------------------------------------- 13:00 WSDL structure issues - Issue X: BEA Simplified Syntax Proposal [16] Overview and initial thoughts. [16] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0071.html Chair: Wants to touch on the BEA issues, simplified syntax and headers/body DaveO: Simple syntax - its hard for humans to write WSDL documents. Thinks that is important. WSDL first implementations are going to be widespread. How can we make the syntax more straightforward? 3 proposals put forth by BEA. First: include things by value instead of by reference. Jonathan: Points out that Sanjiva made a similar inline proposal 9+ months ago Glen: Might not have reached proposal stage, but was involved in rolling up binding atrributes All: Discussion of how an inlined syntax would affect the component model. Arthur: Would make WSDL more like Schema - it is a simplification. Umit: How does it changes the component model? We need to think that through. Roberto: Not convinced this is the 80% case. Creates problems with tools and users when changes or additions are needed. [WilliamV: +1 to what roberto said] Dave: We want to hit the 80% case. We think this does hit it. If you change your mind, yes you have to go to the complicated syntax. Arthur: Agrees that "WSDL first" is taking hold. Likes the inline approach, makes this more like programming languages. Should be baked in to the language. Amy: Does not think it is possible to provide the inline functionality without rewriting the component model. Then we get in to if the content model changes when they are inline. Fairly significant rewrite. [alewis: +1 to Tom (to my *great* surprise ... :-)] [prasad: +1 to opposing inlining. Agree that inlining would only complicate things than simplify. QName based ref is like object programming, define it and reuse it as and where needed. Well understood use case already from WSDL 1.1.] Tom: Firmly opposed to adopting a whole new syntax. This is NOT the way to go about making WSDL simpler, other things we have done (binding, fault roll-up, etc) are better. [sanjiva: +1 to opposing inlining] Jeff: Might be that the changes to the component model wont make it better/worse, but it will take time. Paul: Found that nesting Schema types inline didn't work very well. What will the choice give you? Where is the benefit? [prasad: Likes to see simplification accomplished via facility to assume defaults for things not explicitly supplied rather than via alternate syntax etc.] Arthur: If I can mechanically transform the inline document in to the normal syntax that fits in our component model, why is there any work needed? Amy: If we described the syntax and provided the transform in an appendix, this might work. [prasad: Such mechanism could be private and add on by tools providers than something specified in the spec.] Jonathan: We already have a syntax to model mapping, we would just need to enhance it to describe 2 syntaxes. Phillipe: two different syntax are a bad idea. [alewis: I think I'd be a lot happier if someone were to take the time to make the effort to create a very concrete proposal, showing what changes need to be made, where. I realize that if there's a chance that this might not be accepted, it's hard to commit to the work ... but that goes for the WG, too.] [prasad: +1 to phillipe; We don't need two different syntaxes for people to use] [DaveO: How about if we did some more work on the component model?] [alewis: DaveO, How about if who did what kind of work on the component model?] Umit: Inlining sometimes looks 'sexy' but it turns out it doesn't really make it simpler. [DaveO: either the wsdl wg or BEA..] [alewis: Sorry, that was the ambiguity I was hoping to get resolved. (with the additional choice: proponents of the simplified syntax as an informal group)] Bijan: Is WSDL an authoring format or a message exchange format? Philippe: I'd like to see implication of the proposal on the inheritance mechanism, in particular since we don't allow operation overloading. Jonathan: It has shifted over time, and not shifting as fast to machine only as he would have thought. [alewis: DaveO, If BEA or a small group of WG participants were to offer a proposal that showed "change this, this, this", my ability to evaluate cost and complexity would be greatly enhanced.] [umit: +1 to Amy. ] Dave: To address two syntaxes are bad: In some cases it works out great. Ex: Xpath slash syntax [bijan: I think the XPath example isn't particularly useful as an example] [bijan: For this issue] [umit: The proposal has to take into an account component equivalence and component designators and how they will be affected. ] Dave: Another syntax is XSLT [prasad: I would rather see us put extra effort to try and simplify WSDL syntax rather than come-up with another simpler syntax. I also disagree that tools can not reduce the pain of the language users.] Jonathan: XPath is not a good example. XSLT is a good thing. But isn't sure if WSDL needs this functionality. [KevinL: +1 to prasad.] Roberto: Comparing Schema and RelaxNG inlining makes things much harder for Schema. Tom: Would like to vote on the proposal Jonathan: strawpoll: "How interested are we in pursuing an inline syntax? [prasad: Opposed to inline syntax] [plh-ws: 3/6 (without the phone)] [jjm: pass] [alewis: Opposed.] [KevinL: opposed] [jeffm: I'm opposed to inline syntax] [Allen: Opposed] [prasad: Opposed] [sanjiva: opposed to inline syntax] 3 for, 11 against adding an inline syntax. ------------------------------------------------------- Topic: Simplified elements [dbooth: dbooth notes that it took several minutes to decide whether to take a straw poll, 40 seconds to agree on the straw poll question, and 70 seconds to perform the straw poll.] Dave: the idea is to introduce elements that would reduce the syntax of common (I.e. SOAP over HTTP) WSDL scenarios. Amy: We have already got an approach to this based on the attribute roll-up stuff. Don't see great value in this. [KevinL: instead of introducing new elements, I would strongly prefer that we define defaults.] Tom: Does not think it accomplishes it goal by adding more element to WSDL [prasad: +1 to Kevin. Lets look to simplify things via defaults rather than new syntax. Isn't this the same issue as before in a new bottle :)] Tom: thinks that maybe we have already accomplished lots of this simplification Strawpoll: Should we persue creating new elements (Dave O proposal item #2) [alewis: Opposed] [Allen: Opposed] [prasad: Opposed] [KevinL: opposed] [sanjiva: opposed] [jjm: abstain] [umit: opposed] Results: 2 for, 11 against Dave: Going to drop proposal #3 (a non XML syntax) ------------------------------------------------------- 14:45 Issue X: Headers/Body [17] deferred till after break ------------------------------------------------------- 14:45 Issue 102: Schemas in imported WSDL [18] Review Glen's specese [19] [18] http://tinyurl.com/ysgl#x102 [19] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0017.html Arthur: Why SHOULD instead of MUST? Glen: Some Schema processors might not be able to handle importing components from a WSDL documents directly (I.e. by handle them a chunk of XML). Authur: We should say MUST because it will help interop. Tom: Agrees with Authur, but is worried that someone though we couldn't say MUST. Umit: Says that MUST should not be used. We are putting a burden on the Schema processor which you may not be able to control. Roberto: Agree with Authur. [prasad: I agree w/ Arthur, if that is the desired behavior, lets make that a MUST] Discussion about Schema processors and what they can and can't do. [sanjiva: +1 for changing to "MUST"] [alewis: +1 to Glen.] [prasad: I think this msg captures the issue well: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0148.html] [plh-ws: 'When a schemaLocation is present, it must contain a single URI reference which the schema author warrants will resolve to a serialization of a "schema document" containing the component(s) in the <import>ed namespace referred to elsewhere in the containing schema document. ]] http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#composition-schemaImport] Much discussion about how processors might work and how import works that the scribe was unable to capture/ Jonathan: We seemed to be decided on MUST, but Umit still has a few concerns Aurthur: We should collect examples of documents that may have problems with MUST in the spec. [alewis: +1 to Arthur; use the test cases to insure that the spec defines things unambiguously] Arguments over the wording, including if to include a location or fragment ID. Change SHOULD to MUSt and 'root' ... To "importing" RESOLUTION: Issue 102 is closed with Glens wording with "root" changed to "importing". Time to take a break. Back at 15:25 EST 15:00 Break ------------------------------------------------------- 15:25 Issue X: Headers/Body [17] [17] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0069.html Dave: See [17] for proposal. Describes the proposal. Explicit support for defining headers. Glen: Headers should be in an extension spec, and don't belong in the interface. The one use case I see for headers are cookie-like functionality. Dave: This is saying at the interface level - I expect this header. Glen: If their is anything more complicated then "always put this header" then you should be using features & properties. Dave: We think our proposal allows us to specify optional and required headers and doesn't layer on top of other functionality of WSDL 2.0 - this make it simpler to use. If you have more complicated stuff, then you can go to features. This hit the 80% in straightforward syntax. Roberto: We used to have headers in the interface operations. We removed them. [prasad: The difficulty with introducing concept of "Headers" at the abstract level is that some of the bindings may not have a concept of a "Header". ] Roberto: This proposal is just like what we had and removed with a different name and syntax. This is not really a 'style' in the WSDL sense of the word. Glen: What will this be used for? Dave: If its specified in your interface, you can at least access the types and work with them Umit: We have the facility to do this with features and properties. [alewis: argumentam ad absurdam] Yaron: Why don't we just use F&P for everything? We need an easy way to describe things that the service expects, and I expect WSDL to do that for headers. If we get rid of headers, then we might as well get rid of message bodies too. Glen: Messages are different, with headers you don't know when they might appear and how to use them. Yaron: Sometimes headers are used for versioning and stuff that is application specific. Other headers are more transport specific and perhaps they belong in the binding. In many cases we have application data required or not) we are asking to be able to defined these headers in the interface. Glen: Drilling down in the versioning example - where does the WSDL come from on the old server. Yaron: I have to see the header in the interface, so new clients can know that they can send it. Paul: I don't want to see headers in my application code Umit: We have had this conversation before. [plh-ws: I would note that, while you don't see it in the application code, the content-type header is still useful for the entire application.] [pauld_: want's WSDL to describe the ultimate receiver for a header - what about intermediaries ?] Umit: If we were able to require importing Schema for a feature, then this might help the problem. Sanjiva: The idea of an application header doesn't appeal to me. Security model my be a problem. I like the simplicity of the way we have things now [umit: A soap module or feature may specify a schema. There is an example, OperationName feature specifies such a schema] Dave: HTTP mixes application and app data. Cookies a good example. This is an example of application data in headers. Maybe people will make bad choices and put bad stuff in there, but why are we preventing from doing it Tom: Didn't much support removing headers from the interface, so is in favor of putting them back in. Why should we prevent people from doing that? Yaron: Security model isn't compelling because you will have to sign the headers no matter what. Disturbed by presumption that we know best for users and they have to use features. Also don't much like features so they don't make me happy to have to use them just to set a header. Glen: We will define a feature that will be in WSDL, so everyone will support, that will allow you to define a header. Yaron: I want headers that are purely application specific Sanjiva: It does complicate security. I don't buy the argument that an app will have one header its wants to stick them in. Much more likely that there will be complex rules about when headers appear or don't. WS-Addressing has a reference thing which are like cookies and are not defined in WSDL. Headers just don't go far enough and its not worth it. F&P is the right solution. Dave: We should put security behind us. [umit: Can we have a straw poll?] Yaron: We are talking about a single, very very important, case. Maybe we shouldn't call it header in the interface. There should be this other thing, defined at a syntax level, that will define this kind of app data. [sanjiva: Isn't a <property> the thing that Yaron is referring to? A piece of data that's associated with one or more features?? (Or at least that's what I understand as a property.)] Sanjiva: points out that we have the soap:header in the binding that allows you to put whatever header you want. Yaron: Not good to put these app headers in the binding, doesn't belong there. IF we can take the proposal to have a feature to set a single header with a bunch of elements and change it to be able to have headers in different SOAP headers we might be good. [alewis: there's a tradeoff between validation and extensibility] Yaron: Don't tell users that they can't use headers - we have customers that do it. Glen: We are trying to promote best practices Roberto: Lets see Glens proposal for the feature and stop the discussion. Moving on.... ------------------------------------------------------- 16:00 Issue 95: service/@name required? [20] Options: a) No: remove service/@name b) Yes: close issue. [20] http://tinyurl.com/ysgl#x95 Marsh: Dependency between issue 95 and the service reference stuff which hasn't been fully incorporated into the spec yet. Defer. ------------------------------------------------------- 16:05 Issue 79: How much validation? [21] Options: a) In scope: need volunteer to write up a proposal. b) Out of scope: close issue [21] http://tinyurl.com/ysgl#x79 Umit: This is about conformance. Do you have to understand all of the bindings all of the MEPs etc. Tom: For instance, if I don't understand the out-in MEP am I still in conformance. Amy: If you support at least one you are OK. Can't require everyone to support all MEPs and bindings. DavidB: Two kinds of interop. 1. Interop of 'agents' (client/server). 2. Interop of processors #2 requires a different kind of interopability. We don't have the task to define what the processor does. [alewis: question: is the use of a MEP URL in an operation an implicit wsdl:required?] [TomJ: Discussion about how a processor would treat documents that have things in it that it doesn't understand] [GlenD: amy: yes (imho, natch)] Aurthur: We are a language. All we say in our spec is what a document should have in it to be in our language. [GlenD: Also, have we determined whether a wsdl:required element in a section of the document you aren't caring about needs to be understood to process the sections you do care about?] i.e. is scoping more important or is wsdl:required more important?] Umit: Everything in our spec is normative - you follow our spec you are OK. Even only a section. Is everything in our spec required? [Discussion about what parts of our spec are required, including wsdl:required, Part 2, etc.] Glen: It should be possible to declare a document with wsdl:required and force any processor to handle it. DavidB: We don't want to talk about a WSDL processor, but XML talks about an XML processor. Arthur: Proposes describing what required means in the component model DavidB: volunteers to change the few places in the spec where we talk about a processor without changing the intent. ACTION: David Booth to suggest improvements to the spec clarifying "WSDL processor".] New Issue: Is there something we can do to improve conformance on the wire between WSDL-based agents? This would prevent us from getting immediately profiled.] ------------------------------------------------------- 17:30 Inheritance issues: - Issue 76: Pointing at derived interfaces [22] Options: a) Yes: need volunteer to write up a proposal. b) No: close issue - Issue 81: Account for interface inheritance [23] Options: a) Yes: come up with an alternative. b) No: close issue [22] http://tinyurl.com/ysgl#x76 [23] http://tinyurl.com/ysgl#x81 Deferred. 17:30 Adjourn
Received on Wednesday, 4 February 2004 12:51:07 UTC