Minutes, 11 Nov 2004 WS Description WG FTF

Web Service Description Working Group
Minutes, FTF meeting 11 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
 Arthur Ryman           IBM
 Jerry Thrasher         Lexmark
 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

Thursday 11 November
Scribe: Roberto
Chair: Hugo

09:00 Test suite issues
    - Z update?

Arthur describing the spec draft that has Z in it...
updated spec is
build.xml has been checked into cvs
ACTION:   Hugo to update the makefile to generate the spec with Z
Arthur showing some examples from the spec
Arthur explaining how the collapse/expansion of the Z sections in 
the spec works
Arthur:   we should look at collapsing the infoset mapping sections 
          just like the Z sections
Hugo:     Printed versions should not contain these "hide/show..." links
DBooth:   Have only one link at the top for hiding all sections
Asir:     What is an element content model?
Arthur:   It corresponds to element declaration components (which are
          very well defined by the spec)
[asir:    related LC issue is LC63,
Asir:     There is an issue around uniqueness of type system components 
          given their qualified name (LC63)
Arthur:   Found some problems in the spec while doing the Z translation.
          Will send email.  We may need extension components.
Roberto:  They'd look like annotation components in schema perhaps?
Arthur:   There are references to extension components in the operation 
          name section and the designators section.  We lost the notion 
          of nesting and parenting in the component model.  Components 
          should have the same parenting constraints that are implied 
          by the designators syntax.
Roberto:  For the sake of discussion, could we use Z directly on the 
          infoset view of a description and skip the component model 
Arthur:   The component model may help with include/import.  Z could 
          be seen as adding constraints beyond what XML schema says
Umit:     Got comments that the second level of abstraction (components)
          is foreign
DBooth:   We got a comment to the same effect by Martin Duerst
[pauld:   +1 to losing the component model (if at all possible)]
[kliu:    +1 to paul]
Arthur:   The spec would be shorter; the section on mapping the infoset 
          to the component model could be written as Z
Roberto:  The component model was meant to make the spec writable by 
          humans by making it easier to deal with all the constraints
[DBooth:  +1 to kliu]
Hugo:     Won't Z introduce more problems than the component model does?
Roberto:  The short version will gloss over some details
Umit:     Then people are forced to learn Z to figure out the details
Arthur:   The english would be complete enough for users, but not for 
DBooth:   It's reasonable for an implementor who has a precise question 
          on the meaning to look at the Z notation
Arthur:   We'd be refining the infoset component model, instead of
          two separate models (infoset-based and component-based).  It 
          amounts to specialize the infoset component model
[pauld:   I think the current spec's dependence upon the component model

          means it is targeted too much at developers of tools, rather 
          than authors of WSDL documents]
Glen:     Interesting direction, but it's a major change
[dorchard: +1 to losing component model if possible or at least 
          minimizing the text a WSDL author has to read on how to go 
          from infoset ot component model.]
ACTION:   Arthur to write up a sample of what a rewritten spec using an 
          infoset-based component model would look like
DBooth:   It would be a major improvement to really simplify the spec

10:15 Test suite

Arthur:   There is a test-suite directory in CVS
Arthur describing
Arthur:   Look at the spec and schema, compile a list of every name that

          appears in it (attribute, enumerated value, uri, ...), every 
          name in the vocabulary must appear in at least one test case.
          Additionally, list all test assertions (constraints, etc) and 
          make sure we have at least one "bad" test case that violates 
          that assertion.  Also have a TCP monitor and make sure the 
          messages follow the rules.  Test suite would contain a list of

          WSDLs with corresponding messages.
Roberto:  How does that help passing the "two interoperable
          per feature" barrier?
Anish:    In xmlp we didn't come up with valid soap messages.  Rather we

          invented some semantics for a service, like "echo", described 
          the semantics, then described what's supposed to happen.
Arthur:   I give you (an implementor) a WSDL and an input message; you 
          implement the service; then send the message to the service.
          Same thing for the client.
Roberto:  But it doesn't test interoperability!
Anish:    WS-I defined a sample app, non just a validator
Umit:     Part 1 is seeing whether a WSDL document is a valid document, 
          but that doesn't help interoperability.  Is it the only 
          requirement or more (the test suite)?
Hugo:     Both; the test suite is the tool we use to show
Arthur:   Sent note in April, asking for ways to improve the quality of 
          the spec.  Showing messages that conform to a description
          with that.
Roberto:  For interop, we need something similar to what xmlp did
Arthur:   That was step 2; step 3 is message exchange patterns.  Created

          directories in cvs to check stuff in
[pauld:   you can use the test messages directly, as canned input, or 
          pass them into an implementation, or use them to build a 
          hard-wired implementation at a reference end-point xmlp style]
[pauld:   agreed, for cr we need two or more implementations to
          but the test messages should give something to test individual

          implementations against - in the very least it bootstraps the 
          interop testing]
Anish:    We cannot get away without defining any semantics at all.
          f&p requires semantics.  If you want people like the
          to help, we need semantics.
Arthur:   Call for contributions of test cases
[pauld:   Suggests that it will be interesting to see which aspects of
          spec don't get test cases. could be a useful indication of
          we can expect to be actually implemented. Test suite could 
          become a defacto "profile"]
ACTION:   Arthur to issue a call for test documents
ACTION:   Anish to propose additions to the test suite for the purpose
          interoperability testing.

10:55 Break     ----------------------------------------

11:15 MEP issues
    - Issue LC50: Message Exchange Patterns -- p2c and/or p2e [29]

[29] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC50

DBooth explaining the issue
Sanjiva:   Nodes are logical nodes
DBooth explaining the proposal and its rationale (from
DBooth:    What's the difference between nodes and replyTo?
Sanjiva:   With replyTo, it's still between two (logical) nodes
Anish:     "node" is not defined, MEPs that talk about node N don't mean

           much until we define it.  Bindings may constrain the
           for a reply (e.g. SOAP/HTTP in 1.1 does)
Umit:      When writing MessageDelivery we noticed the multiple
           of "node"
Sanjiva:   Not correct to say that you're violating the binding; we had
           discussion when DaveO proposed an asynchronous binding.  We
           the XMLP group and couldn't come to consensus on their side
           whether the soap response in the HTTP binding has to be in
           HTTP response.
Glen:      If a response comes back with a header targeted to the node
           sent the message, that header must be processed
Sanjiva:   It's still a logical notion
Anish:     With the HTTP binding you can't do that
Sanjiva:   The XMLP group didn't agree. We are talking about WSDL
           in our spec, nothing says that the response has to go to the 
           same address/machine/anything
DBooth:    If the response goes back to the same logical node, I'm ok
           that. With WS-A I can address the response to a different
           does that other location represent the same logical node?
[Anish: Sanjiva -- here is my response to your query on XMLP --
Glen:      Yes, if you're using in-out
DBooth:    Need to exemplify sending a reply back to a different node.
           Proposal is to define a new MEP
Hugo:      How are you going to differentiate between being the same 
           node or a different one?
Roberto:   Applying the 80-20 rule, we shouldn't add a new mep
Anish:     Example of specifying a separate node as the destination for 
           the response
Sanjiva:   Are you doing a request-response?
Anish:     Yes
Umit:      Remove the request-response and define it as p2c. The
           is from the point of view of the service
DBooth:    p2e is a specialization of p2c.  Gudge argued for p2c.  Makes
           argument that both patterns are needed and that tools should 
           recognize the relationship between them
Roberto:   Do not remove p2e.  Cannot just define a super-general
           that covers everything else -- it doesn't help either tools
Sanjiva:   p2e is needed, because p2c cannot be bound to SOAP/HTTP as it

Anish:     You can bind p2c to soap but you have to define new soap meps
           be able to use it
Sanjiva:   We have consensus that you can use replyTo, faultTo with the 
           current meps
Anish:     Given that we haven't defined node, saying that there are
           or just A,B is the same
Umit:      Only one pattern for request-response
Roberto:   meps were from the the service's point of view, but if you 
           allow clients to set replyto, faultto then it is from the
           of view of the client.  Tools will generate patterns and
           things correctly and humans will not have to specify the 
           endpoints and what not]
[Sanjiva: +1 to Roberto]
Roberto:   Client can do what they can and things are logical.  If you 
           want to argue that u want to add this pattern then we have to

           define a binding for it.  Otherwise we should not put it in.
Hugo:      We agree that node is underdefined
Roberto:   Flexibility in the p2c binding translates to additional 
           complexity for developers
Sanjiva:   To use p2c you need to define a new soap mep, not just a new 
Anish:     Do we need to say something more about what a node is?
Hugo:      We agreed to that
DBooth:    Tools could still map p2c to a simple RPC-like form by
           or via a switch that the developer specifies
Sanjiva:   How do you identify A/B/C in p2c?
DBooth:    See spec, part 2, section 2.2.3. Message references are arcs 
           in the diagram
Sanjiva:   Soap meps talk about nodes identified by a URI and that does 
           not imply that it has just one address. We should generalize 
           that definition
DBooth:    WG has become more permissive on what meps to define. Also, 
           addressing extensions have received more attention. A toolkit

           can have an option to treat the generalized pattern as the 
           more specific one
Roberto:   The last point, only on the client side
[pauld:    not sure if this helps, but notes you need two things to pair

           the messages in a request-response MEP - a return path and a 
           correlation. a synchronous transport like HTTP provides both 
Anish:     Ask the XMLP wg to clarify, when using the SOAP/HTTP binding,

           can the response not go in the HTTP response entity body?
ACTION:    Hugo to ask the XMLP wg to clarify the issue around the 
           response in the SOAP/HTTP binding
Kevin:     Given WS-Addressing, why don't we just go back to p2 as a 
           definition of in-out?
  (1) status quo,
  (2) in-out becomes p2c,
  (3) keep in-out as is, add generalized-in-out p2e,
  (4) in-out becomes p2 with conservation of messages
DBooth:    (2) and (4) are the same
[kliu:     for option 4, the question is - do wsdl mep/iop really need
           deal with "client" nodes at all?]
option 1: 8
option 2: 2
option 3: 2
option 4: 1
Hugo:      Any objections to consensus on option 1?
DBooth:    I object because #1 we have been lenient about the meps that 
           we permit, #2 part two is optional, so it wouldn't be harmful

           to add another mep.
Sanjiva:   Would you add any bindings?
DBooth:    Initially, no
Hugo:      Any objections to option 3?
Roberto:   Yes
Sanjiva:   Asks for a formal vote
[pauld:    Found this difficult to follow. thinks in-out should be p2c, 
           but SOAP-HTTP binding could restrict B and C to be the same 
           node. is that covered by option (2) ?]
[DBooth:   yes, paul, that is option 2]
Hugo:      Formal vote on going with option 1 (keeping the status quo)
 IBM: yes
 Oracle: abstain
 WebMethods: yes
 SAP: no
 Sonic: abstain
 RogueWave: yes
 Lexmark: no
 Sun: yes
 W3C: no
 BT: no
 result: 4 yes / 4 no
Hugo: the issue is not closed

ACTION: DBooth and Anish to clarify what a node is

13:00 Lunch     ----------------------------------------

Scribe: kliu

13:45 11:15 MEP issues
    - Issue LC48b: XMLP Review of WSDL 2.0 Part 2 LC WD (b) [28]
    - Issue LC59a: WSDL2.0 Last Call comments (a) [30]
    - Issue LC59c: WSDL2.0 Last Call comments (c) [31]
    - Issue LC76a: WSDL 2.0 LC Comments (Part 2) (a) [32]
    - Issue LC76b: WSDL 2.0 LC Comments (Part 2) (b) [33]
    - Issue LC76c: WSDL 2.0 LC Comments (Part 2) (c) [34]

[28] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC48b
[30] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC59a
[31] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC59c
[32] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC76a
[33] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC76b
[34] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC76c

Topic: Issue LC76a
Issue asks for generalize MEP rules to accomdate ws-addressing
DBooth:   We should generalize the rule to allow "replyTo".  Suppose we 
          define node in a very generic sense, and allow reply to a 
          different location
discussion on what's a node
Hugo:     Postpone issue till the action of clarify node definition is 

Topic: Issue LC48b
Sanjiva, Hugo: Resolution should be add something in part 2 to refer 
          to section 2.3 of part 3 
Asir:     Should be in both part 2 and 3
RESOLUTION: Add text to part 2 and 3 about WSDLMEP and SOAP mep 
          mapping that ponts to section 2.3 of part 3
ACTION:   Editors of part 2 and 3 to add text about WSDLMEP and SOAP mep

          mapping that ponts to section 2.3 of part 3

Topic: Issue 59a
ACTION:   Hugo send email about what HTTP request is when in-only is
Roberto:  If no binding, then no interoperability
Glen:     Agree, remove the out-bound operations to a note
Umit:     It would be hard for some people
Glen, Roberto: they are hard to test
Kevin:    Do we only see wsdl used in the complete sense? does all the 
          bindings have to be defined in wsdl?  See cases that abstract 
          interfaces contains out-bound operations, bindings are 
          provided by infrastructure services.
Sanjiva:  Not all bindings have to be defined in wsdl. but if 
          proprietary, they are not interoperable
Asir:     We should issue a call for implementations of the outboud 
[prasad:  But where do you get bindings for these, when WSDL does not 
          define them]
Hugo:     The question is does everything in our spec has to be 
the proposal from glen: for every mep that we don't have a binding 
          should be moved to a note
amended by asir: if we don't get implementations/applications that 
          requires such mep
Glen:     Since we already have worked it out and have assigned URIs 
          for the meps, we should not just get rid of it. keep it in 
          a note
Prasad:   It's ok to keep it in the spec even if we don't have binding 
          for them. There are already applications that use them.
Sanjiva:  If no binding, no interoperation. the uri of the mep can be 
          definied by whoever needs it
Prasad:   It's intentional that binding in such cases are not available 
          for wsdl
Glen:     If we put those mep in a note, we don't have to follow the 
          rec track requirements
Arthur:   Whoever champion the meps should come up with wsdl binding 
          for them.  Otherwise they should be removed
[prasad:  But, we did not allow that to happen (in the WG) by limiting 
          our scope to the bindings we define now]
Umit:     Our customers use those meps
[pauld:   Over what transport, Umit?]
paul, it could be anything based on the configuration table
ACTION:   hugo to check the HTTP bindings really support the MEPs it 
          claims to support
[Asir:    At risk are .. In-Optional-Out and Out-Optional-In]
[Prasad:  Plus Out-only and Out-In?]
RESOLUTION: In-Optional-Out and Out-Optional-In will be marked at risk 
          when entering CR and will be removed unless we see 2 
          interoperable implementations.

Topic: Issue 59c
Sanjiva:  wsdl1.0 is out of question
Charlton: Examples the ws-chor group can show us
charlton presents the CDL examples comparison of MEPS in WSDL1.1 vs
one-way --> in-only
request-response --> in-out
notification --> out-only
solicit-response --> out-in
All other wsdl2.0 meps do not have counterparts in wsdl1.1
RESOLUTION: we don't think it's necessary for the working group to work 
            on it. Expect third party to chime in

Topic: issue 76b
RESOLUTION: editorial. editors bring it back if see issues

Topic: issue 76C
Glen:     Don't think we should change the mep
Roberto, davidb, glen...: must be delivered is too strong
Glen:     Same case apply to response message
[uyalcina: I think the issue is whether making the delivery of the fault

          or response changes the MEP described]
Roberto, davidB, hugo: fault and response are different
[Prasad:  SHOULD instead of MUST seems appropriate here. I believe WS-I 
          BP did the same thing for this situation.]
Sanjiva, Roberto, Glen: must be delivered vs. must be delivered to 
          binding and transmitted
Hugo:    Amy should know
ACTION:  Hugo to contact Amy with our interpretation and ask for

15:20 SOAP binding
    - Issue LC59b: WSDL2.0 Last Call comments (b) [41]
    - Issue LC61e: comments on the wsdl 2.0 working drafts (e) [42]

[41] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC59b
[42] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC61e

Topic: issue LC61e
group is looking at the issue and trying to decide if we want to 
tackle it today.
Sanjiva:   We already have answers
RESOLUTION: Close with no change to the spec. reply to issue submitter

Topic: issue 59b
[asir: but if you are talking about MTOM, then Glen's e-mail is at
http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0077.html and
RESOLUTION: close with no change to spec. we will suport MTOM. SOAP1.1 
            binding is not part of our recommendation and support for 
            SwA is not part of our plan

15:35 Style issues
    - Issue LC61a: comments on the wsdl 2.0 working drafts (a) [51]
    - Issue LC74d: I18N Comments, WSDL 2.0 Part I (partial) (d) [52]

[51] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC61a
[52] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC74d

Topic: issue 61a
Hugo:     Operation style is move to msg ref
a lot of "what"s in the room
trying to figure out why that change happened and when
Hugo:     Uri style is about the message, not about the operation
Glen:     One still should be able to do it in operation level
Umit:     Agree
it was decided on
issue lc21
ACTION:   Umit to check on operation@style
issue complains style blurs the line b/t interface and binding
Roberto:  Styles such as uri style is defined in http binding. 
Kevin:    Agree with the concern with uri style
Sanjiva:  Rpc style should be moved to part 2, same with other styles
Roberto, Umit: rpc style also defines signature, etc. it's different 
          from uri style
RESOLUTION: Move all the styles and RPC signatures section to part 2. 
            This address the perception concern, no change to the use 
            of the styles.

Topic: issue 74d
Glen:     We can just not say anything about it (the response name)
[hh-chair: Proposal: drop "The LocalPart of the output element's QName 
          is obtained by concatenating the name of the operation and 
          the string value "Response"" from RPC style]
RESOLUTION: close issue 74d as proposed above

15:55 More I18N issues
    - Issue LC74f: I18N Comments, WSDL 2.0 Part I (partial) (f) [60]
    - Issue LC74e: I18N Comments, WSDL 2.0 Part I (partial) (e) [61]

[60] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC74f
[61] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC74e

Topic: issue 74f
Sanjiva:  We don't have a glossary
Arthur:   We don't have a requirement for glossary 
Asir:     This is purely editorial
RESOLUTION: close with no change to spec. reply to issue submitter that 
            we don't have a glossary.if not happen with the definition, 
            let us know.

Topic: issue 74e
Asir:     We should ask one of the editors to come up with a proposed 
ACTION:   Roberto check on comments in 74e and come up with proposal.
Arthur:   What about our support for xsd? only 1.0? Can one tell is 
          an infoset is conformant to a schema?
Asir:     We are trying to re-opening issue 177.

Hugo:     Time to close the meeting.

Thanks webMethods!

16:15  Ajourn

Received on Tuesday, 16 November 2004 20:50:32 UTC