W3C home > Mailing lists > Public > www-ws-desc@w3.org > August 2003

Minutes, 30 July 2003 FTF Raleigh

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 6 Aug 2003 10:12:48 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2AAAD14@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Wednesday 30 July
09:00 Introductions and logistics

 David Booth            W3C
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Macromedia
 Youenn Fablet          Canon
 Steve Graham           Global Grid Forum
 Tom Jordahl            Macromedia
 Philippe Le Hégaret    W3C
 Amelia Lewis           TIBCO
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle (TH-F)
 Dale Moberg            Cyclone Commerce
 Arthur Ryman           IBM
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates (TH-F)
 Jerry Thrasher         Lexmark
 Steve Tuecke           Global Grid Forum
 William Vambenepe      Hewlett-Packard
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Martin Chapmann        Oracle (W)
 Steve Lind             AT&T
 Kevin Canyang Liu      SAP
 Allen Brookes          Rogue Wave Software

 Jean-Jacques Moreau    Canon
 Bijan Parsia           University of Maryland MIND Lab
 Adi Sakala             IONA Technologies
 Bryan Thompson         Hicks & Associates (DARPA)
 (may be others, registration system hiccups prevent a complete list...)

- Assignment of scribes

Draft Scribe List:
Wednesday   AM Jerry
            PM Glen
Thursday    AM Amy (swapped with Jeffsch)
            PM Sanjiva (swapped with DBooth)
Friday      AM Arthur
            PM JeffSch (swapped with Amy)

Agenda Review:
09:10 Publication plan
Survey of remaining work

Part 1: Open proposals:

Major work items for Part 1:

 1. Removing message
 2. Binding enhancements
 3. Attributes
 4. Endpoint references

Other Part 1 ToDo items:

 1. Properties & features guidelines
 2. Describing binary data
 3. ServiceGroup ?
 4. Open issues:
    misc (~7)
    editorial (2)

Part 2: 

Open proposals:

 1. Patterns TF recommendations:

Open issues:

 none known

Part 3: 

Open issues:

 SOAP 1.2 support (~7)
 HTTP binding (~3)
 misc (~11)
 editorial (~11)

Primer: Outline only

Expected Last Call dates?

JMarsh discussed the possibility of last call in the November time frame.
This is dependent on the results of the this F2F (closing remaining
issues in part 1 is requirement). Last call may end up slipping a couple
of months.

09:30 Patterns Task Force (report/recommendations)

DBooth presented the recommendations of the WSD Patterns TF.
Document located at:



4 MEPS in WSDL 1.1
Earlier F2F we decided to look at 8 MEPS.
TF assigned to recommend what MEPS are required/desired 
for WSDL 1.2 and to look at what "properties" of each MEP 
distinguish from another.


DBooth presented and the group discussed the 12 variations of the 
Input/Output pattern and the motivation of each variation (see 
presentation slides).

Current definition of In/Out does not specify the target of the 
Output messageor any generated fault. Hence the variation explosion.

Question? How does Party A(client) in the diagrams know whether to 
expect/wait for a reply/fault from Party S(service) in the In/Out MEP. 
How is this described in the WSDL document?

Outline of the recommendation:

1. Patterns describe MINIMAL behavior.
   (See definition of this concept in the presentation slides)
2. Patterns describe parties as variables
   Any pattern containing more than one message must specify the 
   sender and recipient of each message.

   JeffS pointed out that this implies that some bindings may limit the
   ability to use some MEP's with this specification requirement.....

3. The recommendation for specific MEPs(6 to adopt, 2 to drop)
   TF recommends adopting the following:

 a. Pattern p1a-nf (In-Only pattern)

 b. Pattern p2e-nf (classic In-Out pattern)
    (separate fault rules determine what the output or faults 
    messages can be)  
    (the fault rules that are "matched to the MEP" describe whether the 
    fault terminates the message exchange or not (i.e. can the In-Out 
    generate both a fault and output)
    After discussing in depth the way the faults are treated/applied 
    in this pattern, it was decided (Dbooth) to continue with the 
    pattern discussion/adoption and look at how/what fault rules apply 

 c. Pattern p4c-nf (In-Multi-Out pattern)
    One message (all of the same type) sent zero or more times.

    JeffS asked if there is an implied order to the multi-out messages. 
    DBooth asserted that the "pattern" should specify if order should be 
    preserved. Others asserted that this is a result of the pattern and 
    it's associated binding.
    Was an assertion that MEPs should specify this to allow client code 
    to be written without regard to binding details.

    No decision on whether order is implied or not or how that might
    occur.....revisit if this MEP remains in the specification....

10:45 am  Because of time limits it was decided to press on with the 

  Other MEPS recommended by the TF include:    

  d. Pattern p5a-nf (Out-Only)

  e. Pattern p6b-nf (Out-In)

  f. Pattern p7b-nf (Out-Multi-In)

  TF recommends dropping the following previously defined MEPs:

  a. The "Request-Response" pattern
    (superceded by p2e-nf)

  b. The "Multicast-Solicit-Response" pattern
    (subsumed by p6b-nf)

11:00 - ~11:20 Break

Dbooth presented the patterns that were NOT recommended by the TF and
then outlined the reasoning behind that. (see presentation slides)

Remaining issues form the TF recommendation:

1. Fault Rules.  Could they be simplified to a single message triggers
   fault rules? Current fault rules need to be re-examined.

2. Correspondence/correlation with SOAP MEPs

Discussion on the presentation:

JeffS asked for a clarification on the definition of minimal in the 
first TF assumption.

The concept allows that additional messages and behavior may occur
between client and the service, or between either the client and 
service and other parties, whose details are outside the MEP 

There was some discussion about the idea that a MEP may not fully 
describe ALL interactions between parties.


Sanjiva wants time to further investigate/discuss the TF's recommended
MEPs before deciding to adopt the recommendation. Particularly with
respect to the binding definition of each of the MEPS in the 
specification. Sanjiva asserts that ANY MEP that's included as 
normative in WSDL 1.2 must contain a normative binding definition 
as well.  

There was some consensus, however there was concern that output only 
and output first type MEPs may require extension to the SOAP over HTTP 
binding to be defined.


There were some that wanted to not include any of the "multi" MEPs (i.e.
p4c-nf and p7b-nf) 


It was decided to defer any further change to the TF's recommended MEPs
until they are reviewed further by the group.

TF Recommendations summary (with group opinion):

1. Pattern does not exhaustively define all messages between the named
parties (general consensus)

2. Patterns define only details relevant to more than one party.
(general consensus)

3. As a result of this (2), the participants involved in the pattern 
must be listed. (general consensus) (open issue on it's syntax, what 
attribute etc. and the fault if it's not there)

4. Using recommendations 1 and 2, refine the list of MEPS down to 6 
(see presentation or above for list). (not yet general consensus that 
these are the appropriate MEPS, need more review by the group)

5. Given the MEPs chosen, need to now revisit fault generation rules. 
(consensus that this must be done, but there is currently no proposal 
to review)

*** Action: Amy to generate proposal for (5).

Additional guiding principle that wasn't include by the TF 

6. ANY MEP that's included as normative in WSDL 1.2 must contain a 
normative binding definition as well. (not yet complete consensus)

*** Action: Editors to incorporate the first three recommendations 
into the draft.

The Patterns TF is congratulated for it's efforts and is temporarily 

12:30pm Recess for Lunch.
13:30 Removing message.
      Investigating idea to cleanly separate interop at the message 
      format level from interop at the programming model level. Proposal
      from Sanjiva [4].  Programming hints [5, 6]

  [4] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0025.html
  [5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0114.html
  [6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0120.html

Scribe: Glen

Sanjiva's Presentation re: removing (or not) <message> 
(see archive for PPT) 
Sanjiva:  Complexity (multiple ways of doing things) encourages profiles.
          Might be nice if we did a good enough job to avoid requiring 
          profiling.  Would be great to essentially go with old proposal - 
          duplicate functionality of <complexType> for exactly what we 
Umit:     Yes!
Sanjiva:  Can't prescribe usage; you can always drop to schema/single-
          part systems. Both patterns are already in use today. 
Arthur:   Can't neatly describe some things (unions, com areas, overlays), 
          need full schema. Since these things aren't simple you can't 
          break them into simple parts. 
Umit:     Don't push off the work about defining this stuff to the wsdl 
Sanjiva:  If we retained part, part could ONLY be simpletypes, and you 
          use multiple parts to get structure... people would just go 
          back to 1.1.
In order to support this proposal, you need to add a lot of syntax to 
WSDL on to current proposal. Drop <message>, point <input>/<output>/
<fault> at single <xsd:element>s.
Umit:     Are the body/header QNames disjoint? 
Sanjiva:  Not necessarily 
Amy:      How does header apply outside of SOAP? 
Philippe: Current HTTP binding is based on part names - that's how 
          replacement works.  How does that work?
Sanjiva:  Good Q.  Same question for java binding, etc.... Couldn't send 
          XML over HTTP easily using old bindings.
Philippe: You can with SOAP 1.2.
Tom:      If you specify a fault details QName, you need to put multiple 
          pieces of info inside a wrapper?
Sanjiva:  What does WS-I state?
Jeffsch:  Other stuff (fault code etc) we need to specify about faults, 
          let's hold off on this for a bit.
Sanjiva:  OK not to support more than one element inside <soap:Body> - 
          WS-I already profiled it away, Noah M doesn't so much like it, 
Tom:      There are examples of this in use...

(SOAP encoding discussion)

Tom:      Lots of people working with RPC who want to move to WSDL 1.2.

(consensus to hold off on encoding issue)

(RPC discussion... signature round-tripping, metadata)

Jeff:     Microsoft's position is that we shouldn't be exposing 
          programming models in a normative way... it's about wire msgs.
Martin:   It's not just about roundtripping, it's also about dispatching/
Sanjiva:  Wire is fixed, so the discussion is about bindings.
Jeffsch:  Wire format was, essentially, always fixed, but the fact that 
          there were potentially multiple ways of expressing that in WSDL 
          was a problem.
Martin:   If Signatures -> WSDL is many -> one and WSDL -> Sig is one -> 
          many, we're fine.
Umit:     No, we shouldn't let people generate different signatures from 
          the same WSDL.
Jeffsch:  Our companies may agree on wire formats but we won't agree on 
          programming models - can't force that.
Martin:   By eliminating the operation name on the wire, it means "the 
          name of an instance of an MEP".  So now if I have a schema element 
          representing data (employee record), I need wrapper elements 
          around them to disambiguate operations....
Sanjiva:  The old style="rpc" had the same semantics, just built in to 
          the language.
Jeffsch:  Several names in WSDL that are never evinced on the wire.... 
          we could make that clearer.
Martin:   People do infer semantics from operation names...
Sanjiva:  Could rename <operation> to <interaction> - element syntax to 
          group a set of messages which go back and forth.
Roberto:  WS-I says you need to disambiguate with something that exists 
          in the body itself.
Sanjiva:  SOAPAction can help with this - <interfaceURI>#<operationName>
Roberto:  Operations are more than just groupings if they have element-
          based dispatch (RCP, BP).
Glen:     Why not just say for ALL operations (literal or RPC) you will 
          always see the QName of the operation as the SOAP body child?
Amy:      It's getting SOAPisher and SOAPisher!
Glen:     Dispatch should be on operation information (QName) - doesn't 
          matter how it gets there.
Roberto:  The unique requirement today doesn't force you to wrap, it's 
          just a suggestion.
Sanjiva:  If you don't have a schema for it, it's hard to validate.
Jeffsch:  This is a synthetic element, and there's some overhead there.
          Let's discuss this - it's a choice between automatically adding 
          mechanism at some expense for the middleware, and using a 
          workaround which is known but at some expense for the users.

(moving on to Sanjiva's RPC signature proposal)

Sanjiva:  Use encodingStyle to indicate following a certain set of 
          conventions in the schema.  No default for this attribute.
          Rules are basically SOAP RPC rules, wrapper element with local 
          elements inside, response is "<operation>Response", etc...
Jonathan: Can use custom values for this as well?  What about a list?
Sanjiva:  No lists, was in the original proposal but removed.
Jonathan: What about other metadata people might want to define?
Umit & Roberto: parameterOrder is important - you can have an output 
          param that appears 1st in the signature, for instance...
Jeffsch:  Is it possible to define a single set of rules, tagged with a 
          URI, that encapsulates everything necessary?
Umit:     Maybe, but as my mail said this isn't sufficient yet.
Sanjiva:  This isn't final yet.
Umit:     These rules are OK for RPC over doc/lit - you put the burden on 
          the user to describe the messages.  Everything has to be added 
          and rules have to be followed by the user.  WSDL 1.1 lets us do 
          this "automatically", and this suggestion forces the user to do 
Glen:     Have we gotten rid of style yet?:)
Umit:     I'm afraid writing WSDL by hand will be error-prone and more 
          difficult.  Users will need to convert old WSDLs (write wrapper 
          elements, etc).

(Sanjiva types furiously)

(Sanjiva demonstrates a 1.1 vs 1.2(w/o message) example which looks pretty darn similar)

Tom:      This is wrapped doc/lit.
Roberto:  Messages are already so abstract that people name them fooRequest/
          fooResponse anyway (based on the operation).
Sanjiva:  The problem is that for a given SOAP message, there were/are 
          two different ways to describe it.  This proposal attempts to 
          have one way to do it which is happy for both the RPC (same 
          signature on both sides) and the doc/lit folks.
Martin:   RPC should be a subset of the pure messaging usage.
Umit:     But putting the wrapping burden on the user is bad.
Jeffsch:  Is Oracle more concerned about WSDL generated from code, or 
          WSDL written from scratch?
Martin & Umit: both
Jeffsch:  Since an operation is potentially a group of related messages 
          (not just req/resp), applying method call semantics to it is 
          not necessarily correct.
Martin:   Hey, if we get rid of operation it could be "GET", "POST", 
          etc...:)  (laughter)
Jonathan: How about a break?
Sanjiva:  Can we move forward in this direction?
Tom:      Does this get rid of style?  If not, you can wrap twice (once 
          by user, once by style="RPC")
Amy:      What's happening is that we're moving binding out of binding 
          and into interface.

15:00pm Break

Martin:   Two design centers - start from code, or start from WSDL....
Sanjiva:  If not starting with signatures, there's no huge value to 
          defining schemas to particular rules.  If manually writing 
          WSDL, user has to learn and follow the rules if they have a 
          signature in mind that they wish to encode in the schema
Amy:      Message is dead simple form of schema, and part of the reason 
          for keeping it is that it's easy to understand.  Personally, 
          would like to see WSDL get out of the business of writing a 
          schema language... current stuff is hard to validate, 
          confusing, etc....  would like result (WSDL 1.2) to be easier 
          to plug into a validator.  Maybe instead of removing message 
          we define it such that it's a simple transform away from 
          actual schema....
Roberto:  Message stuff doesn't interact well with existing schema 
          tools - syntactic sugar (new stuff) doesn't help with this
Arthur:   I think we're going to end up starting from schemas, and 
          generating proxies from those, not starting from classes and 
          generating from there.
Umit:     what is the real harm in a syntactic sugar and translation 
          approach?  If rules are simple for machine to follow, should 
          be able to write it....
	<operation name=ncname>
	 <input [element=qname]>
	  <part name=ncname type=qname/>*
Umit:     No minOccurs/maxOccurs....
Sanjiva:  Slippery slope - forget it.
Umit:     But this was the original problem....
Jeffsch:  Lack of expressiveness of message/part - but didn't want to 
          reinvent schema.
Sanjiva:  This is a simplification - especially wait until you see the 
          binding stuff... that gets much easier.
Arthur:   Makes things simpler/clearer
Umit:     we're talking about WSDL', expanded from syntactic sugar.
Sanjiva:  This is a pain for tools vendors, who need to understand the 
          "subset" of schema that part etc. defines.
Amy:      (tossing her "cat among the canaries") Forget about SOAP, 
          consider the next Big Thing... are we writing something that 
          can handle arbitrary other forms of exchanges?
Sanjiva:  This isn't much of a restriction.
Umit:     This is pretty SOAP specific.
Sanjiva:  No, you can bind (for instance) to Java directly....
Tom:      So where are we?

(discussion of syntactic sugar pros/cons)

Amy:      Don't like syntactic sugar because it gets us back into 
          defining a schema language.... maybe we need something 
          different for RPC, but defining wire messages should be 
          delegated to schema/relaxNG/etc.
Umit:     I agree - but it should be simple to translate the "sugary" 
          version to the "real" version.
Sanjiva:  Tools vendors need to support the sugar.
Jeffsch:  But this is really about a human writing the WSDL.
Umit:     I'm not talking about full schema... just min/maxOccurs, 
          nillable, and that's about it.
Sanjiva:  Can we vote about accepting this and perhaps adding syntactic 
          sugar for making it easier for WSDL 1.1 users to write this 
SteveG:   Syntactic sugar isn't a good idea - too complex.  Whole 
          proposal in general is good.
Philippe: Complexity we're removing by getting rid of part, we add again 
          by putting it into the schema.  Syntactic sugar is good.  Don't 
          want <choice>, etc....
Youenn:   Can use XPath with just schema, so syntactic sugar would make 
          that a little harder...
Sanjiva:  If they need to know the mapping from sugar -> elements anyway 
          (to refer to them in bindings, etc), and both exist in the same 
          document (sugar in <input>, reference to the "real" element in 
          binding), that's difficult and confusing.
Jeffsch:  If you want to reach into a particular operation and talk about 
          it in a binding, you need to refer to it in the same way you do 
          at the definition time, OR you need to know the translation 
          rules.  HTTP binding for instance, putting sub-elements into 
          query-string params....
Umit:     OK, it might be not quite ready for prime time.
Tom:      If we're going to get rid of message (which I'm not 100% on), 
          then I don't think we should put stuff in the operation.
David:    Given that the syntax is yukky, a lot of people will be copying 
          and pasting... is there still a need for syntactic sugar then?
Jonathan: What about cut from 1.1 paste to 1.2?
David:    That's a different situation.
Sanjiva:  Doesn't help unless you put it all the way down to bindings as 
Umit:     syntactic sugar is a boon to WSDL-1.1 focused people, of whom 
          there are many.
Sanjiva:  We should talk about getting rid of message first?
Dale:     Not quite baked yet - headers not defined for non-SOAP bindings, 
          etc.  Other type systems seem to have dropped away...?  Edge 
          cases seem a little unclear.
Jonathan: Do we anticipate problems with bindings?
Dale:     Hopefully straightforward.
Roberto:  Do we need the header attribute at all?
Sanjiva:  In 1.1, headers were parts, so wanted to convey same 
Roberto:  So leave it to the binding. This piece goes here, this one goes 
Glen:     I don't think headers belong in there at all.

(brief discussion about headers / modules, tabled until later)

Youenn:   Can element be relaxNG, etc.?
Sanjiva:  What I had in mind was a QName pointing to schema.... but maybe...
Dale:     encodingStyle rules would need to be different for relaxNG, 
          so you'd need a different URI.
Jeffsch:  I think we could define a set of rules over a known set of 
          schema languages under a single URI.  But we might need a new 
          URI for new unforseen schema languages....
Alan:     Very wary of the whole idea of syntactic sugar, especially if 
          there are additions above and beyond WSDL 1.1 syntax.  Generally 
          in favor of the rest of the proposal.
Kevin:    Generally in favor, but some concerns about backwards 
          compatibility.... rename to WSDL 2.0?
Umit:     How normative is this?
Jeffsch:  If you care about interfaces, you confirm that they followed 
          the rule.  If you don't, you just ignore it.
Umit:     You should fatally fault if the rules are specified but not 
          followed regardless of whether or not you use the information.
Jonathan: OK, so a document which screwed this up could be considered 
          non-conformant, but still be usefully utilized in some contexts.
          This is a separate issue, let's deal with it separately.

Consensus is that it's OK to ignore invalid stuff contained inside ignored 
(or not understood) extensions.  But it's not OK to have invalid stuff in 
the parts of WSDL you do understand.

Umit:     You need to make this encodingStyle thing required, and all 
          processors must verify it.

ISSUE: What does a WSDL processor do when it encounters invalid constructs 
which it does not care about?

Jonathan: Let's vote.  Two ways to proceed.  1) refine the proposal further 
          (syntactic sugar etc) first, and then vote, or 2) vote on the 
          proposal first and open issues against it.  Would people vote 
          differently depending on which way we went?

Proposed order of voting/decisions:

1) Remove message per Sanjiva's proposal (@body, @header)
2) Add hints re: method signatures
3) Proposed rules for schema writing
4) Add syntactic sugar for operation -> schema

Umit:     What about the other proposal?  Essentially Sanjiva's old 
          proposal - introduce parts in <input>/<output> with minOccurs/
          maxOccurs, but without the "implied schema" step.  Rename 
          operation -> messageExchange?
Tom:      What about SOAP encoding?
Sanjiva:  This is a binding discussion - wait 'til later, but maybe we 
          can reintroduce use or something....
Tom:      Don't want this to get overlooked.
Arthur:   Part was good for mime types.  Have we decided how to deal with 
          that with schema?
Sanjiva:  We can do the PASWA thing.

Jonathan asks for objections to 1+2+3 above.

Oracle objects.

VOTE: 1 + 2 + 3 above

W3C: Yes
Sun: Yes
Macromedia: Yes
Canon: Abstain
Grid: Yes
Tibco: Yes
Cyclone: Yes
IBM: Yes
Microsoft: Yes
Lexmark: Yes
HP: Yes
Oracle: No
Rogue Wave: Yes
SAP: Abstain

11 yes
1 no
2 abstentions

Straw poll on #4: Should we adopt some form of syntactic sugar to better support the RPC use case in the operation construct?

In favor: 2
Not: 9

Umit Objects to recording consensus to not investigate

17:30pm Ajourn
Received on Wednesday, 6 August 2003 13:13:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:43 UTC