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

Minutes, 10 Nov 2004 WS Description WG FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 16 Nov 2004 12:47:54 -0800
Message-ID: <7DA77BF2392448449D094BCEF67569A505AA1B15@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Working Group
Minutes, FTF meeting 10 November 2004
Sunnyvale, hosted by webMethods


 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Youenn Fablet          Canon
 Hugo Haas              W3C
 Anish Karmarkar        Oracle
 Kevin Canyang Liu      SAP
 Jonathan Marsh         Chair (Microsoft)
 Arthur Ryman           IBM
 Jerry Thrasher         Lexmark (afternoon)
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         SAP
 Prasad Yendluri        webMethods, Inc.

 Paul Downey            British Telecommunications
 Jean-Jacques Moreau    Canon
 David Orchard          BEA Systems

 Tom Jordahl            Macromedia
 Dale Moberg            Cyclone Commerce
 Mark Nottingham        BEA Systems
 Bijan Parsia           University of Maryland MIND Lab

Wednesday 10 November

Scribe: Youenn

09:00 SOAP 1.1 Binding
    - First draft [35]
    - Modified Part 3 (aka, added soap version) [36]
    - Modified XML Schema for SOAP in WSDL 2.0 [37]


Presentation by Asir
Asir explains changes made to the spec to make the soap version works
Asir:     Added the soap:version @ and changed the value of type.  Now 
          it is soap (previously was soap12).  New section 2.4 to 
          describe soap:version
Jonathan: We do not have default schema values for attributes in the 
          rest of the spec and there is a default 1.2 value for 
Asir:     Should move the default value in section 2.4.4.
RESOLUTION: Move the default attribute value in section 2.4.4 to the 
            mapping rule table.
Asir:     Remove all direct ref to soap12 and introduce a new section
          Section 2.10: soap1.2 binding. Section 2.10.3 defines the 
          defaulting rules for soap1.2 binding (soap action...)
Sanjiva:  We had some text for the supported wsdl mep in the soap1.2 
          binding.  We do not say anywhere which wsdl meps are supported
Asir:     To be added in the text.  Same should be true with soap1.1.
          We could claim that either at the soap binding level or both 
          at soap1.2 and soap1.1 binding level
RESOLUTION: Add text indicating which MEPs are supported by the SOAP 1.2
            and SOAP 1.1 bindings.
Presentation of the schema
Hugo:     How have you abstracted soap modules from soap12?
Asir:     It is in section 2.7.  Removed all direct reference to 
          soap1.2, otherwise it is the same
Hugo:     We should define it because we are extracting modules from 
          soap12 to apply it on soap11.  This section might not make 
          sense for somebody that did not know anything about soap12
Glen:     Since it is only a concept, no problem applying it in soap11
Asir:     Section 2.7.1 should reference to the soap12 rec. soap11 
          binding is a very small spec. Introduce new names: one for 
          the http binding, one for the req-resp mep and one for the 
          one_way mep
Sanjiva:  What does feature name means in soap11?  If these are the 
          only features that are defined, we should remove ref to 
          security, reliability, etc.  Tthese things should be modules
          in the binding, we identify the soap11 binding using the 
          version @
Asir:     The term soap module is defined for soap11. Section 3.3 
          defines default binding rules when version is 1.1
Asir describes soap action, soap mep selection and http method 
          selection default rules
Anish:    No value for soap action should map to ""
Jonathan: what about soap fault subcodes
Asir:     One way is to remove it from soap binding and put it in the 
          soap 1.2. The other way is to ignore them when using soap11
Sanjiva:  The latter option is better
[Anish:   SOAPACTION HTTP header field for SOAP 1.1 --
Asir:     Add to the text the "ignore fault codes and subcodes for 
          soap11" rule
RESOLUTION: Add to the text the "ignore fault codes and subcodes for
            soap 1.1
Sanjiva:  In soap11 spec, there is no definition of a soap11 
RESOLUTION: Drop the soap11 mep ref in section 3.3
Sanjiva:  We should ignore the soap mep value whe using soap 11 binding 
          and remove the SOAP mep selection text, and the same should 
          apply for the http method selection.  http method is always 
          http post. http method value should also be ignored
RESOLUTION: remove the http method selection and soap mep selection
Anish:    When using the soap one way mep, you cannot return a soap 
          envelope.  The http response must be empty (quoted from BP)
[Anish: bp 1.1 --
Hugo:     We are working on soap11 binding for backward compatibility 
discussions on supporting soap11 one way mep
Umit:     A lot of ws-i work is bug fixes. We should refer to that work
Jonathan: These bug fixes are only valid for the basic profile
Anish:    We should fill the holes of wsdl11 soap11 binding
Sanjiva clarifies the proposal
Sanjiva:  Which wsdl meps are bound to the soap11 binding? only in-out 
          and in-only
Asir:     First proposal is soap mep should be ignored in the wsdl 
          soap11 binding
discussions now about http binding supporting out-in wsdl mep
Sanjiva:  The proposal is that we support in-out and in-only
[Hugo: Decision about the HTTP binding:
Sanjiva:  If the wsdl mep is in-only, the http response is undefined 
          but should be empty if following the basic profile
Jonathan: The purpose of using the wsdl soap11 binding is to migrate 
          a service from wsdl11 to wsdl2 without having to fix the 
          service/server implementation/configuration
discussions on the scope and purpose of the soap11 binding
discussions on whether refering to ws-i bp from the wsdl soap11 binding
or not
Jonathan: Add a non normative reference to bp within the wsdl soap11 
          binding spec explaining how in-only wsdl mep maps to soap11 
          over HTTP
RESOLUTION: add a non-normative reference to BP within the soap 1.1
          spec as explanation of how in-only WSDL MEP maps to soap 1.1
ISSUE: make sure in-only mep is supported in wsdl soap12 binding
Hugo:     Soap modules are identified by uris. We should say in the 
          spec that soap11 module authors should identify their module 
          with a uri
RESOLUTION: Add text in section 3.2 that soap modules in 11 are adopted 
            from SOAP12 and then soap11 modules need to have a uri.
RESOLUTION: drop SOAP feature in 11 binding and define one URI for
            HTTP binding
Hugo:     We should say that this binding is for backward compatibility
          per the charter
RESOLUTION: add mention info from charter to soap11 intro
Glen:     I do not want our spec to require support the soap11 binding 
          if supporting the soap12 binding
Jonathan: It is then clearer to have the soap11 binding as a note
Hugo:     The charter says that soap11 binding will be a note. If we
          to change this, we should ammend the charter.  If we follow
          REC track for soap11 binding, this raises the bar. It is
          to keep it as a note
  2 for pursuing folding the SOAP11 binding into the spec, 
  12 against
Consensus to adopt Asir proposal as a working draft
Consensus to adopt Asir part3 changes to accommodate the soap11 binding
ACTION: Asir to implement resolutions adopted at this FTF.
ACTION: Part 3 Editors to roll in Asir's changes.
Jonathan: We should then publish the drafts after making the changes in 
          the specs.

10:40 Break     ----------------------------------------

11:10 Fault Component placement
    - Issue LC19: Fault Component Re-usable Across Interfaces [12]
      + Asir detailed binding changes [13]
    - Issue LC75a: WSDL 2.0 LC Comments (a) [14]

[12] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC19
[13] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0057.html
[14] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75a

Umit:     We should allow override the reason of exception in different 
Roberto:  Is this discussion about overriding the reason of a fault or 
          also the code at the operation level
Glen:     Should code and subcode be changeable? No. The code is meant 
          to define the fault type in soap.
Umit:     The same exception can be raised for two different reasons
Roberto:  The code is similar to the type of the exception in java
Glen:     We should be able to add soap modules to soap faults because 
          these are also messages
Roberto:  The fault instance will have the same detail data type but 
          not the same detail data
Asir:     For the same geds, we can have multiple faults with different 
          fault codes
Umit:     The question may be whether to set the reason of the fault if 
          we know it in advance
Glen:     We could create a new fault or have a fault detail with a 
          choice in it.  Reason is totally runtime and we should not 
          have a means to set it in wsdl
Sanjiva:  It is realistic to have several operations of an interface 
          sending the same fault.
discussions about Asir proposal to promote faults as top elements
Roberto:  Interface inheritance is usable to reuse faults within 
First question to answer is whether to promote faults at the top level
Asir:     Fault components are not globally reusable
Sanjiva:  Fault has a concept which is more than an element
discussion on using interfaces inheritance for enabling fault reuse
Roberto:  It is easier to have them in the interface than to have them 
          global.  If global, you would need to go through all 
          operations and dereference the referenced faults
Sanjiva:  If we allow top level faults, it would be natural to bind 
          the faults independently
Asir:     This is the second level of reusability.  The first level is 
          reuse at the abstract level and the other at the binding level
Sanjiva:  If we do not do both, then the solution will be half baked.
          We should do both or keep them at the interface level
Asir:     This is difficult at the binding level
Sanjiva:  Then it is half baked
[pauld:   jeff says fault references are the same as messageRef, why 
          don't the reuse issues (which abstract faults attempted to 
          resolve) apply to messages?]
Sanjiva:  If we promote faults at the top level, we should allow binding

          them at the top level also which is very costly
[pauld:   Notes hyperdictionary.com says "half-baked" means "a screwball

          proposal without a prayer of working" ..]
Umit:     Why do we need to bind faults at the top level?
[pauld:   it was in sunnyvale one year ago!]
[pauld:   and JeffSch was there!]
[GlenD: :)]
[Sanjiva: paul, was webmethods there too? ;-)]
[pauld:   lilly and prasad :-)]
[GlenD:   As the originator of the pull-up proposal in the first place, 
          Paul, what do you think of this?]
Asir:     For the generation case, reusability at the abstract level is 
[GlenD:   Leave them in the iface, or pull them up further?]
Strawpoll: Lift abstract faults at the top level or leave them at the 
           interface level?
3 for option 1
6 for option 2
Jonathan: Can we live with the status quo ?
no objection to close issue LC19
RESOLUTION: Issue LC19 closed without action.

TOPIC: Issue LC75A
Sanjiva:  In the code to wsdl generation case, it is natural to have an 
          interface with operations that share the same exceptions
[pauld:   basically saying i'm divided in opinion - i agreed with much 
          of what jeff said in his email, in particular what's special 
          about faults? - esp when describing an exisitng message 
          exchange bottom-up (tooling could have a problem abstracting 
          the faults). but when writing WSDL first top down, abstract 
          faults (and even hoisting them even higher) has great merit 
          IMO. so i'm divided between jeff and Asir's proposals and 
          therefore chickened out and abstained.]
Sanjiva:  Sharing of faults is a common case
Jonathan: Any objection to close 75a with no action ?
consensus to reject LC75a
RESOLUTION: Issue LC75a closed without action.
ACTION:   Sanjiva to write the rationale for rejecting LC75a

12:00 SOAP binding
    - Issue LC55: binding/operation/infault|outfault? [38]
    - Issue LC56: Clarification for binding fault [39]
    - Issue LC61d: comments on the wsdl 2.0 working drafts (d) [40]

[38] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC55
[39] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC56
[40] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC61d

Jonathan: Issue LC55, LC56, LC61d appear to be essentially duplicates
Glen:     Good if we can bind infault or outfault like saying use 
          this encryption module when sending this fault.  If I can 
          put a module for an input, I should be able to put it for 
          an infault|outfault on a per operation basis without having 
          to rewrite a module
Sanjiva:  We made this design on an 80/20 case
Roberto:  It seems strange to not have infault and outfault in the spec
Jonathan: We should maybe add a rationale in the spec
Roberto:  it would look like input and output at the binding level
            <infault ref="fault qname">
Sanjiva:  We could add infault and outfault and restrain them to include

          only soap:module and extensions, not set the code and subcode
Glen:     Sounds right
ACTION:   Roberto to write up the addition of infault and outfault at
          binding level plus modifications at the component model.

12:15 Lunch     ----------------------------------------

Scribe: Arthur


13:15 January F2F Planning
Jonathan: is proposing January 24 in Melbourne to co-locate with 
Sanjiva:  objects on the date since the gap until the next meeting is 
          too short
Jonathan: says there will be a 5-week period until our following
          March 3-4
Jonathan: has requested March 3-4, to be confirmed
Sanjiva prefers an earlier date
Jonathan: Is Jan 10 better?
Roberto:  Prefers Jan 24
Jonathan: Jan 13-14?
[Week of the 17th appears to be preferable to those in attendance.]
[dorchard: btw, I will not be attending a Jan 13-14th WSDL meeting in 
           Australia. Who is the host?]
[Roberto: BEA]
[dorchard: When did BEA offer to host on Jan 13-14th?]
[Sanjiva: DaveO: We decided to ask BEA to resched to Jan13-14th as 
          that was the preferred wg position]
[Roberto: I don't think you did. simply, the wsd wg would prefer that

13:30 Formal Objections recap
    - Features and Properties [46]
      + Glen's presentation to CC Workshop [47]
    - Lack of compositors [48]
      + Issue LC59f: WSDL2.0 Last Call comments (f) [49]
    - Unique GEDs [50]

[46] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0375.html
[47] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0060.html
[48] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0371.html
[49] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC59f
[50] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0376.html

Glen:     Recap - IBM, Microsoft, SAP object to F & P.  Sonic, IONA, 
          Oracle, Sun object to lack of compositors.
Glen:     Proposes to put F&P into Part 2.  In exchange, add compositors

          to F&P.  Simplify proposal for compositors based on Cannes 
          suggestions.  F&P is very similar to WS-Policy.  Motivation is

          to motivate spec writers to identify important parts of spec
Anish:    Glen, is your proposal atomic
Glen:     It's a compromise
Sanjiva:  WS-Policy is more generally useful than WSDL. If F&P is in a 
          separate extension, does that imply it is more generally
Glen:     Nothing prevents anyone from using elements from the WSDL 
          namespace more generally.  The main point is that it is a 
          pre-defined extension, not that it has its own namespace
Jonathan: F&P is essentially optional, aside from encountering required 
          ones.  The benefits of putting it in an extension are minimal 
          since if you don't want to support F&P you just have to fail 
          when you encounter a required one.
Kevin:    Users will have to chose between Ws-Policy and F&P
Glen:     I hope W3C creates a standard in this space
Asir:     Such a W3C WG may never get formed
[Anish:   c&c workshop -- http://www.w3.org/2004/09/ws-cc-program]
Asir:     The C&C workshop did not agree to form a WG 
Sanjiva:  The C&C conclusions do not reference F&P
Jonathan: We discussed the comprise, next step is to see if it is
Glen:     Sonic supports the comprise.  The compositor proposal will be 
          simpler than the original
Asir:     We need to see the simplification
Glen:     I request a straw poll to see if this is a reasonable proposal
Asir:     How simple is the compositor
Glen:     And, Or, Not. Nested compositors is included
Sanjiva:  You need to define equivalence rules of boolean compositions,
Jonathan: Do the simplified compositors satisfy the objectors
[pauld:   original proposal for compositors: 
Glen:     Let's at least decide that this is a good direction to move in

          with the aim of removing the objections.
Jonathan: Since IONA and Microsoft are absent we can't decide.
Glen:     We have IBM, Oracle, Sun, SAP.
Sanjiva:  I need to review this proposal at IBM. IMHO, we should make
          work in the context of SOAP modules and not have an abstract
          solution.  E.g. if we need compositors for SOAP modules, then
          should add them.  Moving F&P to Part 2 doesn't make much of a 
          practical difference.
Kevin:    I need to go back to SAP to discuss it.
Roberto:  I disagree that this just needs to work in the SOAP context
          it is useful for other protocols.  I think this is a good 
Anish:    Oracle would like to see this in the main spec, but this is a 
          good compromise. I would like to hear the responses from the 
          other companies.
Jonathan: From the Microsoft viewpoint, this does not seem like a
          compromise since compositors add a lot but moving the
          from part 1 to 2 doesn't change very much in practice.
[pauld:   I have to applaud Glen's attempt to achieve consensus, but 
          worry deeply about how complex the WSD spec is as it stands. 
          Adding compositors even as an 'extension' could be 'jumping 
          the shark', IMO.]
Jonathan: What is the evolvability story? How will F&P come together 
          with WS-Policy?
Sanjiva:  Is Ws-Policy was submitted to W3C would you remove F&P?
Glen:     No, because it would take too much time.  It's important that 
          stable names/identifiers get assigned to specs so that spec 
          writers can refer to them.
Hugo:     Question: Are you saying that the simplified proposal would 
          be developed quickly enough for WSDL 2.0?
[pauld:   Suspects that if ws-policy was submitted tomorrow and followed

          the anticipated ws-addressing track, it could still be a rec 
          before WSDL :-(]
Roberto:  There is a good start on the proposal which was submitted 6 
          months ago.  I objected to the process followed. Adequate 
          consideration was not given.
Glen:     To answer Hugo, I estimate 1 month.
Jonathan: We need to get a brief sketch of the compositor proposal.
ACTION:   Glen will post an e-mail describing the proposal.

Topic: Unique GED Objection
[DBooth: http://www.w3.org/2004/Talks/1110-DBooth-opname/]
DBooth now is presenting the proposal at the given URL
IBM. Microsoft, TIBCO filed the objection
Slide 8:  Only DBooth interprets the spec wrt to the client requirement
Slide 10: Sanjiva objects to point 5 since client and service use
          toolkits. DBooth asserts that Sanjiva is describing a
DBooth recommends on slide 12 to augment the spec
ACTION:   DBooth will produce text for the spec

15:25 Break     ----------------------------------------

16:00 Unique GED Objection (cont.)

[Roberto: on slide 15, "no verb" = POST]
DBooth presents recommendation on slide 22
DBooth:   Slide 25 summary
DBooth:   End of presentation
Jonathan: How does this address the objection?
DBooth:   The current wording in the spec needs to be modified
ACTION:   Editor remove ambiguity if it exists
ACTION:   Jonathan to create 3 new issues from slide 25 on points 1, 2,
          and 4
Sanjiva:  is presenting thoughts on the granularity issue, moving the 
          requirement down to the message level to enable service to 
          distinguish, e.g., between multiple inputs of the same GED
Jonathan: You are asserting that Web services deal with verb+message, 
          not message, and that operations, interfaces, etc. are just 
          convenient ways to group them
Glen:     The tuple (service, operation, message) needs to be conveyed.
          Convey does not mean literally transmit
Sanjiva:  Proposes a solution: add an {opcode} property to 
          MessageReference component, define an algorithm for a 
          default, allow user to set, must be unique across an interface
Anish:    The {opcode} should be unique across all interfaces.
Sanjiva:  Now define this at the binding, i.e. SOAP 1.2
ACTION:   Sanjiva will write up this proposal and email it to the list 
          as a response to the objection

17:15 Adjourn
Received on Tuesday, 16 November 2004 20:48:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:45 UTC