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

Minutes: 3 Nov 2003 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 7 Nov 2003 15:16:52 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA201B62765@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Group
Minutes, FTF meeting 3-5 November 2003
Sunnyvale, hosted by Fujitsu.

--------------------------------------------------------
Monday 3 November
--------------------------------------------------------
Present:

 David Booth                  W3C
 Allen Brookes                Rogue Wave Software
 Roberto Chinnici             Sun Microsystems
 Glen Daniels                 Sonic Software
 Paul Downey                  British Telecommunications
 Youenn Fablet                Canon
 Tom Jordahl                  Macromedia
 Jacek Kopecky                Systinet
 Philippe Le Hégaret          W3C
 Amelia Lewis (phone)         TIBCO
 Kevin Canyang Liu            SAP
 Lily Liu                     webMethods
 Jonathan Marsh               Chair (Microsoft)
 Jeff Mischkinsky             Oracle
 Dale Moberg                  Cyclone Commerce
 Jean-Jacques Moreau (phone)  Canon
 Bijan Parsia                 University of Maryland MIND Lab
 Jeffrey Schlimmer            Microsoft
 Jerry Thrasher               Lexmark
 William Vambenepe            Hewlett-Packard
 Sanjiva Weerawarana          IBM
 Umit Yalcinalp               Oracle
 Prasad Yendluri              webMethods, Inc.

Observers:
 David Martin                 SWSI

Scribe: Bijan
IRC:    http://www.w3.org/2003/11/03-ws-desc-irc

--------------------------------------------------------
09:00 Introductions and logistics
    - Assignment of scribes
        Bijan Parsia (Mon AM)
        Kevin Liu (Mon PM)
        Paul Downey (Tue AM)
        Dale Moberg (Tue PM)
        Lily Liu (Wed AM)
    - Agenda fine-tuning
    - Reviewing parts 1 and 2 for publication

Sanjiva:  Please review HTTP binding, esp.
Marsh:    Review all three documents by wed, for informed vote.

    - Charter extension (Jan 04 expiration date)

Sanjiva:  like last call in march
Marsh:    If we hit LC in march, we need another year to get through Rec.
          If we miss March, then we need at least 18 months
Sanjiva:  If we hit CR and PR, do we still meet every two months?
Marsh, Glen, etc.: YES! CR is a hard working time
Marsh:    Continues asking people if they have products they need to sych 
          2.0 with. No response, so, seems like we have product cycle 
          slack. So maybe take that slack to do it "right" (or add goodies)
Sanjiva:  I really want a March LC. Will throttle down participation round
          then (or hopes to)
JeffSch:  What's the status of asking for charter extensions? Is it 
          costly? Can we ask for time in dribs and drabs?
Phillipe & Marsh: Possible but costly for team.
[Lots of process discussion.]
Marsh:    2 month lc, then a month to deal with lc coments, then 2 month CR 
          (depending on then current implementation status), then a bit 
          before going to PR, then a month
[Scribe now transcribes JeffSch's whiteboard Gnattish chart]
  LC
    LC Period                        2 months
    Address Comments                 2 months
  CR
    CR Period                        2 months
    Address Implementation Feedback  1 month
  PR
    AC Vote                          1 month
    Director Review                  1 month
  REC! Small tasteful party in Austraila
  Errata                             6 months
]
JeffSch:  How much buffer?
Philippe: It's not a matter of buffer, but of deadline and how the group 
          works.
JeffSch:  I'm just trying to set a realistic schedule, given the group, etc.
Marsh:    Buffer of 3 months before PR. Plus, I think March is way 
          optimistic.
Sanjiva:  But we can move specs separately
Marsh:    I'd like to "lock down" part 1, at least internally, for a 
          while, then focus on other stuff. Maybe aim to lock down Parts 
          1 & 2 by Jan meeting, then work on bindings for March.
Sanjiva:  Looks like, for the sake of charter extension, we should aim for 
          18 months.
Marsh:    I hear JeffSch and Sanjiva saying we should *really* aim for 
          March, but maybe that's fatigue with process :)  Is the WG willing 
          to set an LC deadline of...January?
WG:       Stunned disbelief, fear, and trembling
Sanjiva:  There's not much left in Part 1
Marsh:    Scale of Part 1 has been shrinking
Glen:     March is possible, perhaps, but dependant on what happens when we 
          dive into part 3
[Ok, replicating JeffSch chart, again, but only the date bits.]
  LC                                            1&2:March 04  3:May 04
    LC Period                        2 months
    Address Comments                 2 months
  CR                                            Oct 04
    CR Period                        2 months
    Address Implementation Feedback  1 month
  PR                                            Jan-Apr 05
    AC Vote                          1 month
    Director Review                  1 month
  REC! Small tasteful party in Austraila        Mar-Jun 05
  Errata                             6 months
]
Sanjiva:  Process note: If we're going to make March or May, we need to 
          insist that WG make comments and proposals by Jan
Glen:     But sometimes implementation experience of a "more settled" spec 
          reveals issues late in the game
[Some general agreement that WG members need to do serious review work, 
preferably by the end of the year.]
Marsh:    What's left to decide on [long list that the scribe had no hope 
          of transcribing]
[jjm:     Scribe, the list included things such as features, headers, 
          endpointReference]
Umit:     what about implemenation problems?
Sanjiva:  First, I want WG members to committ to working early and second, 
          there's a place for the general impl issues.
Umit:     I shall double my email correspondence.
[jjm:     Sanjiva, MTOM may have some impact on Part 1 as well (infoset, 
          schemas), especially now that it's been split into a SOAP-agnostic 
          and a SOAP-specific part]
[Some discussion about what we can and can't split out from the "base spec" 
and deal with separately.]
Philippe: Do we forsee future, post 2.0, work (e.g., additional bindings, 
          WSDL 2.1)?
Glen:     Bindings, fine. but if we need to do 2.1, we've done something 
          wrong with 2.0.
Marsh:    We still have, e.g., RDF bindings
Glen:     How to connect descriptions to higher level semantics is really 
          interesting, but perhaps for a group like ours (not us?)
[Philippe, JeffSch, determined that Philippe wants to ask for 2 years (to 
cover the Errata period)]
TomJ:     We should put pressure our ourselves to do better. We should try 
          the "Macromedia way": *When* do we want a spec and work backwards.
Marsh:    The Whiteboard schedule will go into the charter.
TomJ:     Sure we don't want to aim for Jan for the spec?
Marsh, Glen, others: not actually possible
Sanjiva:  Who plans to implemenation WSDL 2.0?
Marsh:    We need to know who's going to implement *before* we get to CR.
Glen:     Apache is going to be agreessive.
JacekK:   Systinet(?) will
Bijan:    UMD/MIND Lab intends an implemenation (fairly agressively)

RESOLVED: Prepare 24 month extension.

--------------------------------------------------------
09:20 Faults.
    - Fault refs pointing to more than one message [3]
    - Proposal for faults [4]; revised proposal [5]
    - binding different fault details differently for same @messageRef
      value) Optional name?  Allow optional
      /definitions/binding/operation/fault/@details to be the selector?
      Waiting for a motivating use case.

  [3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0213.html
  [4] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0250.html
  [5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0051.html

Marsh:    I put this on since TomJ thought it could use another hour, 
          and perhaps Sanjiva has another proposal(?)  Is there an open 
          issue or confusion on faults?
Sanjiva:  There is one, mulitple faults and how to name them. there's no 
          use case.
Umit:     Q about use case. What if someone wanted to have a header fault 
          and refer to an existing fault? With no name, you can't do it.
Sanjiva:  What's a header fault?
Glen:     Header fault is like a confirmation code.
[Scribe and Umit confused']
Glen:     [explantation] "We should go for it"
Roberto:  If we don't have the name, then the right way to refer to a 
          fault is by message reference and detail (unique in the context 
          of an operation).
Sanjiva:  Now we're talking about the binding.
Roberto:  No, it could be anything! RDF!
Sanjiva:  In the spec, [missed by Scribe]
Glen:     Our abstract conception of a fault is just an element. Can't 
          reasonably layer SOAP semantics on that.
Roberto:  Found the bit in the spec: 2.5.1
Glen:     You need unique details
Roberto:  No, just the unique combination. Which operation, which message 
          ref, and details. And refering to faults is so rare, that it 
          being this hard is ok.
Sanjiva:  You need to compare it with the input case, not general 
          components. Roberto, you make the point that fault ref is hard, 
          but compare with input [scribe lost]
Roberto:  We should give it a name, that would go in the abstract componant 
          model.
Sanjiva:  What's the use case?
Roberto:  See above.
Sanjiva:  Does anyone want to push this sort of use case?
Glen:     Easier than Umit's header, is that in the soap world you can have 
          two messages that only differ on fault code. Need name.
Roberto:  It should show up in the details
Glen:     That imposes a uniqueness requirement on the details element. I'd 
          like to take out the details element, add a name, and let the 
          bindings take care of it.
TomJ:     Call it detail, or call it message.
JacekK:   The issue is do we want faults to carry information(?) in the 
          abstract model.
[Several people, Roberto, Umit, Glen, strongly agreed with JacekK's 
formulation. Rather, they strongly said, Yes we want that.]
[TomJ writing, in very tiny letters on whiteboard, example of WSDL markup 
for faults. Scribe attempts a transcription:
  <interface>
    <operation> in/out
      <input messageref="A" body="x:in"/>
      <output messageref="B" body="x:out"/>
      <outfault name="myfautl" <---name not in spec (yet?)
                messageref="B"
                details="nsfaultXML"/> 
    </operation>
  </interface>
  <binding>
    <soap:binding>
      <operation>
        <outfault name="myFault" <--attribute also under discussion, not in the spec (yet?)
                  messageref="B"/>
          <wsoap:faultCode="s:receiver"/>
          <wsoap:subcode="app:bad"/>
        </outfault>
      </operation>
    </soap:binding>
  </binding>
]
TomJ:     So what happens if we "get rid of" [sanjeeva corrects, we don't 
          have name, yet]
JeffSch:  What if details didn't show up in the abstract part?
JacekK:   It seems that JeffSch is saying that faults shouldn't have...
          [something]
JeffSch:  For soap, at least, the information for describing faults is in 
          two different places, which is confusing. Two possibilities: 
          Consolidate the info. Or add a name.
Sanjiva:  Third possibility: have details in outfault instead of binding.
TomJ:     For the abstract part of the description, we have a fault. Let's 
          say I'm making the operation into a java sig. If I don't have 
          details, I need at least the name.
JeffSch:  It's like the RPC programming hint.
TomJ:     I want a name (or something) in the abstract part to hang my hat 
          on (chorus of agreement)
JeffSch:  Is it ok if that name doesn't show up on the wire?
TomJ:     I'd like also to have all the needed info in the abstract part. 
          Which connects to what goes on the wire.
Paul:     Faults and messages are quite different, and binding dependent.
TomJ:     (this is hard in WSDL1.1 because you need all sorts of stuff)
          Add a name, keep the details and i can general langauge 
          interfaces, and have all the info I need in the abstract place. 
          I have the name, and I have a schema description of the xml 
          which I can use to generate the relevant type.  Hey! Names on 
          all the faults!
Sanjiva:  The anti-name: We don't need name. We don't have a use case.
          The right way to refer to it was [something]
[TomJ adds a proposed name attribute to outfault (value "fault2") for 
discussion. Contention twixt TomJ, Glen, and sanjive over the reality 
of this new example.]
Glen:     Use case: Stack trace.
Sanjiva:  We've changed the question: Now details isn't unique.
[Abstract outfault details value to ns:faultxml2.]
Sanjiva:  Solution is to add details to binding outfault
JeffSch:  This example is code first driven. In protocol design you may 
          not even have a details. In writing protocol descriptions, I'm 
          careful to describe various *kinds* of fault. On this design, 
          I have to make up some stuff. 80-90% of the descriptoins I 
          write won't have a details.
[PaulD:   agrees with JeffSch]
TomJ:     Names help JeffSch!
Sanjiva:  Another solution, move details down to the binding.
JacekK:   In reply to JeffSch, we're agreed that faults carry at least 
          one piece of data. So generalizing it to a whole xml structure 
          is a good compromise. We may have one piece of xml data 
          associated with different faults. "Details" is the wrong name, 
          since it's only one piece of fault data soap (e.g.,) carries. 
          We want to describe *ALL* the data. So rename to "message".
Glen:     We'd include in the schema a GED that does this
Roberto:  I agree with Jacek. Each of these messages should have a well 
          defined payload. Now I'm in agreement with Sanjiva. Name doesn't 
          seem to simplify programming language binding.
Glen:     what about JeffSch's test case?
Sanjiva:  Can be handled
Glen:     So you need to define a GED with no content? That's harder than 
          a name.
Sanjiva:  If you want to add content in a binding, extend the schema 
          definition.
TomJ:     So, my java exceptions are named by the details content
Roberto:  And that's better, because you are using types, not names!
Umit:     I am against taking out details form abstract and moving entirely 
          to binding.
TomJ:     I proposed putting names in both places. Problem: If we don't 
          have name, then we need details in both places. My rejoiner, 
          we're overthinking. Names are nice to look at!
JacekK:   So long as you specify that for two names, the details can be 
          different.
JeffSch:  I would like to express my future protocol descriptions in 
          WSDL. Current design: I need a superflous extra GED. What if we 
          migrated fault codes up to interface. Say, "statusCode" 
          attribute on, e.g., outfault?  In faults, tends to have 3 kinds 
          of info: Code, info string, and then a data structure (completely 
          dependent on recognizing the code)
Glen:     Name solves that problem!
JeffSch:  That could work. So long as no need for unique details, etc.
Glen:     +1
JeffSch:  Hey! This will work great!
[PaulD:   +1]
Glen:     If we add a name, so you can use codes to differeniate exception 
          types, and don't require details or unique details, we have 
          everything we need for determining the faults "type".
JacekK:   How would this work with SOAP? To which code or subcode do you map 
          to?
JeffSch, Glen: In the binding.
TomJ:     JeffSch reproposed my proposal.
Sanjiva:  I'm more comfortable with "code" or "statusCode" than "name"
[Discussion arising out of details of name vs. code, diving down into 
implication for mapping to programming languages. TomJ vs. Sanjiva, 
essentially.]
TomJ:     Concedes a problem about how to constrain name (e.g., unique where?) 
          correctly.
Roberto:  Current uniqueness is msgref+details, we should now have unique 
          msgref+name within operation.
Sanjiva:  Two faults in two different operations can have the same name, when 
          langauge binding you end up with two different things.
PaulD:    Hoist faults up to the top level of interface
Sanjiva:  Is the proposal that we change the componant model.
Glen, TomJ: yes, but this solves the problem
Glen:     We have a lits of faults, so uniqueness is handled, and all the
          operations can use them.  I propose that someone write up the 
          proposal, e.g., Paul.
PaulD:    takes on the proposal job.
JeffSch:  why doesn't name or code as a child of interface, operation, 
          outfault do this job.
Glen:     Referring to the same fault type in different operations is difficult.
          This lets the model explicitly *Say* that they are the same fault, 
          instead of relying on the processer to figure this out.
[scribe will transcribe TomJs poster:
  <interface>
    <fault name="f1"
           details="x:myfault"/>
    <operation...>
      <input>
      <output>
      <faults name="f1"
              messageReference="B"/>
      <outfault name="f2"
                messageReference="B"/>
      ...
]
[Discussion of infault and outfault to bring Glen up to speed..]
TomJ:      Putting i, n and o, u, t into wsdl is the least of our confusions.
           Summarizes: Tom & others wanted names on faults.  JeffSch agreed 
           but maybe with different name, e.g., code. Sanjiva brought up bugs
           Paul brilliantly suggests hoisting the faults.
JeffSch:   Point of optimization of syntax: I've expressed a pointer between 
           an input or output and a fault, why not embedd?
Glen:      You can't.
JeffSch:   Details optional?
TomJ & Glen: why not?
Glen:      Do it!
JeffSch:   Summarizes the proposal as applied to his use case
Umit:      JeffSch, is your problem that now the abstract level is now looking 
           like or too the binding?  Actually the other way round: binding 
           leaking up to the abstract level.
TomJ:      Faults weren't right in 1.1. I want them easier to implement in 2.0. 
           It worries me that Sanjiva is on the "wrong" side from me.
Sanjiva:   The only thing worrying me at the moment is that it makes faults 
           first class citizens.
PaulD:     That's a plus to me
Sanjiva:   If you look at a programming langauge design, you don't separate 
           them. We need to work through the details, and we're trying to 
           publish.
Marsh:     It doesn't sound like faults is ready, especially as we have a 
           fairly extreme redesign.
TomJ:      Ok, can we live with the problems of either less rad examples?
Umit:      TomJ, you never answered Sanjiva, why can't you live with 
           details/message as a wrapper?
Glen:      We want to say what type the fault is without having to have 
           anything show up on the wire.
Roberto:   But that's different from the wildly praised radical direction, 
           fault is like a GED schema thingy
Glen:      Rebuts with soapy arguments.
Sanjiva:   JeffSch made a good point about the "three things" of a fault. 
           Details was intended to cover the payload part, but we don't have 
           anything for the fault code part. I think it's fine to add that
[Discussion of Roberto's "it's a rename of xs:element" point, with Glen and 
JacekK objecting, Sanjiva, Roberto and Umit insisting.]
JacekK:    We want to be able to say, for code, exactly what goes on the 
           wire. There must be something *set* for a fault and it must be 
           something outside of the xml schema.
Sanjiva:   I think JacekK agrees with me.
JacekK:    Yes
Sanjiva:   Code and details should be distinct. Abstractly, that looks good 
           and nicely general. Bonus: it maps nicely to SOAP (though we need 
           not be bound by being nice to map to SOAP.)
Glen:      If I have two different operations with same fault ref, then in 
           my soap binding I have two places where I potentailly have to bind 
           something, so I have to make them match and express them in both 
           places.
Roberto:   Not necessarily. Context will help
Glen:      I need to bind "that" name to a heirachy of soap codes. Don't want 
           that at the abstract layer, but in the soap binding. I need to 
           repeat the info and check the bindings. The Top Level approach 
           solves this problem.
Roberto:   Prefer to solve this with a binding shorthand
Glen:      That would work, but PaulD's solution is cleaner.  It's not code, 
           but it's a name.
Sanjiva:   We add a name attribute to infault and outfault in abstract 
           operations, make details optional. Inside binding we add infault 
           and outfault and inside them we use the same keys to reference back.
           Separate discussion about simplifying the binding syntax. (Here 
           ends Sanjiva's proposal)
TomJ:      We don't have in/outfault in bindings?
Sanjiva:   No, but we need it
TomJ:      So we're going to add it.
Marsh:     Yes
[JeffSch, editing above stuff in real time, projected:
  <interface>
    <operation ...>
      <input messageRef='xs:NCName'
             body='xs:QName'
              ... />
      <outfault name='xs:NCName'
                // maps to binding/operation/outfault/@name
                messageRef='xs:NCName'
                // maps to interface/operation/input/@messageRef
                detail='xs:QName'? 
                // probably rename]
      />
    </operation>
  </interface>
  <binding>
    <operation>
      <outfault name='xs:NCName'> 
        <wsoap:Code>
          <wsoap:Value>xs:QName</wsoap:Value>
          <wsoap:Subcode>
            <wsoap:Value>xs:QName</wsoap:Value>
          </wsoap:Subcode>
        </wsoap:Code>
      </outfault>
    </operation>
  </binding>
]
[Looking at the soap binding part. Some discussion about the need 
for subcodes and subsubcode.]s
Sanjiva:  Syntax easily supports it so why not.
Roberto:  Need a msgref on outfault as well (in binding).
[So, name & messageRef on binding/operation/outfault.]
TomJ:     I have concerns with this messageRef thingy.
Sanjiva:  messageRefs maps to field in pattern.
JeffSch:  Describes the fast typing person enacting a web service (fast 
          reader, as she has some wsdl printed out beside her)
          messageRef (on fault) indicates which message the fault replaces.
Glen:     It's more common that you're going to have a sit where one 
          messageRef with several different fault names, than the reverse.
TomJ:     What are we hashing out?
JeffSch:  Didn't understand the proposal. want to get some concrete syntax 
          up there to bring us all on the same page
Glen:     The difference between the proposals, PaulD's, you can use only 
          the name of the fault, you can take the name and bind it in a 
          particular way. In the other proposal, it's trickier and that's 
          why you need lots of messageRefs
JacekK:   If we go with the PaulD proposals, would the binding specify just 
          one binding for the fault?  Then we don't need the messageRef 
          attribute in the binding.
Glen:     Instead of first class faults, we leave them in the operations 
          and make them scoped to the entire interface. and the names may 
          be reused after first declaration.  Why would you want to bind 
          somethign differently if in or out? Isn't it just a message?
PaulD:    It's just information that something's gone wrong. You don't 
          care where it's coming from.
TomJ:     We're losing the focus my standing up brought.  We've had this 
          conversation twice.
Umit & Scribe: Three time!
Sanjiva:  If hoisting is right, we should do it even if it's a big change.
          My intuition is that hoisting isn't done that way in programming 
          languages.
Glen, TomJ, Bijan: Wait, it is done that way.
[Dicussion between Sanjiva and Glen; Glen is again accused of 
soapcentricity.]
TomJ:     It's still valid to talk about faults as distinct from 
          input/output messages. Seems like Umit & Roberto are wanting to 
          go back on that distinction.
Roberto:  This feels like the message discussion all over again.
JeffSch:  The reason we are in this design trough is due to the requirement 
          that if a fault occurs in >1 operations, map to the same exception 
          type. With requirement, we go toward PaulD's proposal. Otherwise, 
          otherwise.
Glen:     +1
Sanjiva:  The requiremnt is a programming model issue.
Glen:     No, it's also a wsdl writing issue. More times to repeat, the 
          more times it can screw up.
[PaulD:   Duplication too - it's a many (interface/operation/message) to many
          (binding/operation/message) relationship]
Sanjiva:  Ok, redundant info reduction fine. but the other requirement is 
          still a lang binding issue
Glen:     Can we go faults within operation syntax & if it's used twice, 
          then it's the same thing.
Sanjiva:  If you use the same name, then the details must be the same. 
TomJ:     You can define a fault with a name + some payload, and that fault 
          can be in or out. And refs to message A, B, C, D, etc.
[Scribe misses some subtle weirdness binding thing that Roberto's raised 
and Glen tries to squash.]
[Roberto: You could have two <infault/> in the same operation for different 
          message references.]
JeffSch points to requirement: Allow fault to occur in both an infault and 
          an outfault.
JeffSch:  That's sufficent to generate Roberto's cases.  You replicate the 
          interface structure in the binding, then you decorate, with 
          arbitrary fine detail
Glen:     (after some JeffSch & PaulD driven discussion + Roberto) we're 
          80% of the way to a proposal!
[Lots of discussion with people being pretty happy with the state of things.]
Glen:     But codeDefault must be worked out. Add to binding 
            wsoap:FaultDefault name = 'xs:NCName"><wsoap:Code>...</wsoap:Code>...
JeffSch:  We are able to drill down in soap binding to specific messages 
          to specific stuff
Sanjiva:  We don't have these any more
Glen & Umit: So does that mean the wg doesn't want to support SOAP 1.2 RPC?
[General clamor to defer that discussion.]
[JeffSch adds the details of various proposals to his document, which will be 
forwarded to the scribe for sharing purposes.]
Sanjiva:  Lets get enough together to take some sort of vote
PaulD:    I'm not sure my proposal is worked out enough to face a vote
Glen:     My question: if you can override what faultdefault says, are you 
          diluting the value of the reason you put it there in the first 
          place?
[Exchange between Glen and JeffSch following up on Glen's question. 
Discussion resolves to "that's not so bad" from Glen, JeffSch, and TomJ. 
(if only scribe understood what it was that wasn't so bad).]
JeffSch:  Stuff about subcode expressed in a code that Glen understands 
          but scribe doesn't.
[TomJ:    Tom thinks that being able to override the faultDefault isn't so 
          good for implementations (disagreeing with the 'not so bad' feeling)]
TomJ:     Don't override faultdefault
Sanjiva:  So faultdefault is just fault
TomJ:     Yes!
Glen:     This argument goes back over to MEP. If you use the same thing 
          in differnt places to mean differnt things its not the same 
          thing so you should give a different name.
[Scribe notes that it seems that the "universal argument" seems to have 
been discovered. Everyone claims that the same argument is good against 
everything.]
Marsh:    Can we go with a default with overrides for now?
[Lots of violent discussion. No one's proposed going back to 1.1.]
TomJ:     Ok, we can life with faultdefault *for now*
Glen:     Does anyone other than PaulD, me, and maybe TomJ have interest
          in PaulD's proposal and developing it?
TomJ:     I like the idea but I'm also in favor of finishing the spec more.
          The Standard Rant about How the Group Embracing Radical Changes 
          Except When He Likes It
Sanjiva:  Should we adopt the incremental change and then work on the 
          radical one *for the sake of publication"
Marsh:    Ibid.
TomJ:     Yes! That's my original proposal anyway.
JeffSch:  Labels the three proposals in his doc
Marsh:    I was merging 1 and 2
Glen:     I don't want 1 without 2
[Note that everywhere you see messageref == messageReference]
Marsh:    Proposal 1: Adding name to faults...[scribe has no hope]
JeffSch:  Stuff marked in red in my document
DBooth:   Trying to get clarity on what we're deciding
TomJ:     Are we embedding all the wsoap:FaultDefault, etc.
[Scribe clarifies: Proposal 1 is clearly marked in JeffSch's document which 
will be included in the minutes. 
See http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0025.html

  <interface ... >
    <operation ...>
      <input messageReference='xs:NCName' // maps to field in pattern
             body='xs:QName'
             ... />
      <outfault name='xs:NCName'
                // target for binding/operation/outfault/@name
                // if used twice, means the same fault
                messageReference='xs:NCName'
                // maps to interface/operation/{input,output}/@messageRef
                // may match other faults in interface w/ same @name
                detail='xs:QName'?
                // must match other faults in interface w/ same @name
                ... />
    </operation>
  </interface>

  <binding ... >
    <wsoap:FaultDefault name='xs:NCName' >
      // rollup like other operation-specific information
      // good for all instances of @name
      // explicitly does not include @messageRef
      <wsoap:Code> ... </wsoap:Code>
    </wsoap:FaultDefault>
    <operation ... >
      <outfault name='xs:NCName'
                messageReference='xs:NCName'
                // required because same @name can occur within an
                // interface/operation with different @messageRef
      >
        // overrides binding/wsoap:FaultDefault with same @name
        <wsoap:Code>
          <wsoap:Value>xs:QName</wsoap:Value>
          <wsoap:Subcode>
            <wsoap:Value>xs:QName</wsoap:Value>
            <wsoap:Subcode> ... </wsoap:Subcode>
          </wsoap:Subcode>
        </wsoap:Code>
        // Detail is just interface/operation/outfault/@detail
      </outfault>
    </operation>
  </binding>
]

Sanjiva:  I'm fine with body for now, but want to revisit during the headers 
          discussion.
TomJ:     I like detail
Glen:     Given the @name, the names of the rest isn't as critical
TomJ:     My objection: detail carries *good* baggage for soap people
JeffSch:  Can no one live with detail?
Marsh:    So, we're sticking for detail.

APPROVED: Proposal 1 (see JeffSch's document)
ACTION:   PaulD to work out his proposal in more detail
Marsh:    Rearranging the agenda for the sake of moving the Patterns 
          discussion to tomorrow for the sake of the remote folks

--------------------------------------------------------
12:30 Lunch
--------------------------------------------------------
Scribe: Kevin

13:30 RPC-style rules
  - Syncing rules with SOAP 1.2 RPC [8]
  - Clearer statement of normativity [9,10]
 
  [8] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0059.html
  [9] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0057.html
 [10] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0062.html

Current status: Sanjiva has put a marker in the ED of part 1, Umit has 
sUmitted issues and proposals.
[Sanjiva: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0007.html]
Looking into the current spec section 2.3.1.1
[TomJ: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl20.html#InterfaceOperationStyle]
DBooth:   Should not talk about what the WSDL processors do or not do, 
          should only focus on what wsdl documents are or are not.
          Specification implies what the services it interacts must do.
JeffM:    Schema defines what the message needs to look like on the 
          wire.
[Second part of Oracle proposal is related to schema.  More discussion 
on if the second paragraph in the above section is right.]
Jeff, Sanjiva, Umit: we need to be clear about is schema is conformant 
          to what's specified in the RPC style.
Jaccek:   Has a proposal for rephrasing the sentence
[JacekK:  http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0026.html]
Jaccek:   It's the reader to follow the rules if the style has a value.
[JacekK:  If the {style} property has a value, it implies the rules that 
          were used to define the properties of that operation component.]
Sanjiva:  Should be "the rules must have been followed" (by the writer?)
[JacekK:  If the {style} property has a value and the properties of the 
          operation component do not follow the rules specified by the 
          style property, the WSDL is in error]
JeffM:    We don't have a model for WSDL processors. 
[Roberto: "It is an error if the {style} property has a value and the 
          rules associated to it have not been followed"]
[Let's say if a schema doesn't follow the rpc rules, it's an error.]
DBooth:   Two things. a) schema must be conformant to the rules, 
          b) a message must be conformant to the rules
[DBooth explain his digram in the whiteboard:  wsdl spec defines the wsdl 
          definitions which in turn defines the behavior of the services 
          and conformances of message.
Sanjiva:  We agree the rules must be followed in defining the schema, 
          those that not follow are errors.
Jaccek:   Points out maybe it's more than schema conformance.
Marsh:    Concerned it's sort of circluar (missed what's the it?)
[Sanjiva: Note that the property MAY not have any value. If this property 
          has a given value, then the rules implied by that value (URI) 
          MUST be followed or it is an error.]
[Marsh: JeffM: Messages MUST conform to the schema.]
[DBooth:  ACTION: JeffM to propose text to the effect that messages must 
          conform to their schemas.]
Sanjiva:  Will reword the first paragraph
[PaulD:   Concerned that message may legitimately contain *more* 
          information than defined in the schema, Glen cited encryption ..]
Marsh:    Looks like we will delete the second paragraph.
Jeff:     If the style has a value for rpc and the schema doesn't follow 
          the rules, the document is considered not conformant
[now looking into the rpc style rules]
Umit:     Made rewordings suggestion in emails
[group compares the suggestions and the current ED draft.  Umit's proposal 
is at http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0007.html]
DBooth:   why do we need to say a child elements may contain nillable, 
          minoccurs, etc
JacekK, DBooth: it's really not a rule
[Philippe: s/xsi:Nillable/nillable/]
ACTION:   Sanjiva make a clarification "note that" kind of text to replace 
          the third bullet points in rpc rules
[fourth bullet: must all --> MUST both. (scribe may messed up the bullet 
numbers. the above is for the sentence "Input and output elements MUST 
all be in the same namespace")]
[next rule: The complex type that defines the body of an input or an output
element MUST NOT contain any attributes. Clarification : "third bullet" is 
"The child elements MAY contain the following attributes: xsi:Nillable, 
minOccurs and maxOccurs."]
[Roberto writes on the white board exploring how the "same namespace" rule 
works in case one interface inherites another.]
[next rule: The complex type that defines the body of an input or an output
element MUST NOT contain any attributes (accepted)]
[next rule: If an element that appears as a child of an input element also
appears as a child of an output element, it MUST be declared by
using the same type. (group is ok with the above rule).
Jaccek:   need one more rule
[JacekK:  The input|output sequence MUST NOT contain multiple children 
          element declarations with the same name]
[Sanjiva: <item><p> If elements with the same qualified name appear
          as children of both the input and output elements, then
          it MUST be declared by using the same type.</p></item>]
[Now move on to rules after the paragraph "Furhermore, the following rules 
MAY BE used to map between a message and a signature of a remote procedure 
call. These rules are suggested conventions to accomodate mapping."]
[rule: If an element is a child of the input element and an element
with the same name is not a child of the output element, then it
represents an input parameter.]
[Need wordsmithing.]
[rule: The parameter order is specified by using the parameterOrder attribute.
Sanjiva: parameterorder is out of the spec
[Roberto: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0347.html]
Umit:     If we don't say anything about parameter order, the spec is not complete
TomJ:     What's the problem?
Umit, JacekK: without parameter order, one can not tell the return value
reberto explains his proposal expressed in the url above
[JacekK: counterproposal: parameterOrder contains *ALL* parameters (excl. 
return value) using a list of QNames; if parameterOrder is missing, parameter 
order and return value is unspecified]
JacekK:   signature should be Qname
Roberto:  it's qname
JacekK:   the structure is complicate
Sanjiva:  the signature thing has nothing to do with what's on the wire. Likes 
          the proposal. 
(missed Sanjiva's concern)
TomJ & Umit: two problems need to be resolved: order and return value 
[more discussions about the proposal. scribe fails to capture the minutes]
JacekK:   A non-signature comment. if it's a one way, the rules will break.
          the rules could say we have to use one of the two meps: in-out and 
          in.
[PaulD:   now we've accepted we are going to have IDL in/inout/out etc. Likes 
          Roberto's syntax as it can can handle multiple returns and could be 
          easily added to in the future without breaking the comp-model]
JacekK:   it's a principle in W3C that microstructure inside a simple type 
          is considered no good
[more discussion on the use of xsd]
[JacekK:
  <input ...>
    <sequence>
      <input>a</input>
      <output>b</output>
      <result>c</result>
    </sequence>
  </input>
]
JacekK:   This is Roberto proposal amended
Roberto:  The use of ## in my proposal is what XSD use for wildcards
[PaulD:   looks forward to Savas and Mark Baker's reaction to this ..]
JeffSch:  Let's treat Roberto proposal as status quo and ask those who have 
          issues for improvement.
Marsh:    Is it possible to have two styles for rpc?
[(one of the two styles can define the parameter order stuff). look into 
that later.  Discussions on multiple return values.]
PaulD:    Would like to add constraints to Roberto proposal not allowing 
          re-ordering parameters.
Roberto:  The following needs to go to the spec under RPC style:
          The spec for the rpc:signature extension would state all the usual
          requirements (all parameters MUST appear, all in parameters MUST
          be present in the input message and MUST NOT be in the output, etc.).
Marsh:    Any objection to adopt Roberto proposal?
[hear no objection. we adopt the proposal]
[Prasad:  Please note the optional / hint nature of all this. Just trying to 
          make sure that aspect does not fall through the cracks.]
ACTION:   Sanjiva to put note in spec to reflect the decision of adopting 
          Roberto proposal

15:00 Break
--------------------------------------------------------
15:20 Update from David O on TAG progress on WSDL Component Designators

David:    The group asked the TAG about the use of fragement identifier 
          in namespace URI.  The answer from TAG is Yes.  TAG raised a 
          new issue (issue 40).  TAG considers frag id as a good idea.
          There were discussions on use dot separator.
ACITON:   Marsh put in future agenda for discussion on TAG feedback on 
          frag id
[Philippe: TAG (draft) finding: http://www.w3.org/2001/tag/doc/abstractComponentRefs-20031030]
Sanjiva:  Concern on fragid approach: it's only defined with mediatype.
[Philippe: RFC2396bis: http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
           fragment identifiers: 
           http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#fragment]

--------------------------------------------------------
15:45 Uniqueness on the wire
   - Proposal from Umit [11]

 [11] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0112.html

Marsh:     Summarizes two sides of the discussions: jeffM indicate that WS-I 
           has required the message must be unique in the wire; JeffSch doesn't 
           see it necessary.
[Umit's proposal is at http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0112.html.]
Marsh, Umit: the core of the issue is dispatching the message to the right operation
[Umit: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0121.html]
Sanjiva:   Needs to understand the problem better: the service provider knows 
           the message it's expecting and know how to dispatch it
[Umit, DBooth, Glen give their reasonings]
TomJ:      if you are the service provider and doesn't provide enough info in 
           WSDL, you screw up
Umit, JeffM: no
[DBooth:   If a WSD has two operations, both of which are output-only, and the 
           message schemas are the same, then a client may have trouble 
           dispatching, even though the service doesn't have a problem.
Glen:      Not sure if we can mandate something here
Umit:      There should be a standard way to distinguish messages
DBooth:    We agreed to distinguish messages in wsdl, it makes sense to do the 
           same for the wire message.
Umit, Glen: yes
[more discussion on if headers are about infrastructure or application]
TomJ:      Let's stop talking about header:)
[PaulD:    An RPC over an async transport has to dispatch the response to the 
           client.]
[discusison back and forth if we need standard way to distinguish messages]
JacekK:    A non-proposal: let's just note this issue in the spec 
DBooth:    Should be in the primer
[Sanjiva:  +1 to primer.]
[JacekK:   and note the "unique GEDs" solution as a possibility.]
Marsh:     There are multiple ways to resolve this. concerned just choosing 
           one will limit the possibilities.
[more discussion on Glen's proposal on using feature to resolve this.]
Umit:      The issue is about how to relate a message to a operation, let's 
           focus on it
[direction under discussion: define a required feature for dispatching. it's 
           an error if a wsdl/message doesn't support that feature.]
PaulD, Sanjiva: we don't have to do anything: we already have the mechanism 
           for one to reference a feature. one can just define a feature for 
           dispatching and require it in wsdl.
Glen:      Maybe we need to make the feature a citizen of wsdl so we can 
           guarantee it will be around 
Sanjiva:   The proposal is that we observe in the primer this is an issue. 
           The way to solve it is to use feature and property. the question 
           now is should we define the feature.
Marsh:     Primer will add simple example that enables message dispatching. 
           Someone need to write proposal for dispatching features using 
           soap action, and GED
JeffSch:   Why do we need to decide on one way now while there are many 
           different future worlds?
Roberto:   Doesn't have to be GED, will be happy if WSDL add A property
           for dispatching.
[Glen, Roberto, JeffSch debate on why now]
[the group is getting tired of the repeated discussion, looking for proposals 
for moving forward.]
Marsh:     Seems we are rejecting Umit's original proposal of requiring GED 
           in all wsdl
[Roberto:  http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0121.html]
Strawpoll 1. adopting the GED proposal from Umit/Roberto
             for: 5, oppose 11
JeffM:     How many think the requirement should be addressed some way?
strawpoll 2. each wsdl must have a required feature associated with dispatching 
             for 3, against 13
strawpoll 3. enable people to indicate so in normative way
             for 13, against 3
Marsh:    We will pursue the normative feature idea.  Now we need some body 
          to write the features up.
ACTION:   Umit (with help of Glen) will write up a proposal for normative 
          dispatching feature.

--------------------------------------------------------
18:00 Adjourn
Received on Friday, 7 November 2003 18:16:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:27 GMT