W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2004

Minutes: 29 Jan 2004 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 4 Feb 2004 09:49:30 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2027A6BCB@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:02 UTC