FW: [corrected] Minutes, 15 July 2004 WS Desc telcon

[Corrected as per

Web Services Description Working Group
Minutes: 15 July 2004 telcon

 Erik Ackerman          Lexmark
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Helen Chen             Agfa-Gevaert N. V.
 Roberto Chinnici       Sun Microsystems
 Ugo Corda              SeeBeyond
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Hugo Haas              W3C
 Tom Jordahl            Macromedia
 Amelia Lewis           TIBCO
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Dale Moberg            Cyclone Commerce
 Mark Nottingham        BEA Systems
 David Orchard          BEA Systems
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

  Youenn Fablet          Canon
  Martin Gudgin          Microsoft
  Jacek Kopecky          DERI
  Kevin Canyang Liu      SAP
  Peter Madziak          Agfa-Gevaert N. V.
  Jean-Jacques Moreau    Canon
  Bijan Parsia           University of Maryland MIND Lab
  Arthur Ryman           IBM
  Jerry Thrasher         Lexmark


1.  Assign scribe.  Lucky minute taker for this week is one of:
      Adi Sakala, Umit Yalcinalp, Igor Sedukhin, Dale Moberg, 
      Hugo Haas, David Orchard, Jerry Thrasher, Allen Brookes

Scribe: Hugo

2.  Approval of minutes:
  - July 8 [.1] 

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0109.html

Postponed until next week
Waiting for MarkN

3.  Review of Action items [.1].
PENDING   2004-04-01: Marsh will get schema tf going.
?ED       2004-05-19: Editors to include in the primer an example 
                      that uses MTOM.  (Issue 72) 
?ED       2004-05-20: Editors to incorporate Hugo's full potato 
                      proposal.  (Issue 54)

Discussions around the full potato proposal
Hugo: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0244.html
is missing

?ED       2004-05-20: David Orchard to update HTTP binding to 
                      include discussion of how to generate an 
                      accepts header from schema annotations 
                      conformant to the media types extension 
                      document, and to use outputSerialization 
                      based on that information.  

Accept header discussion: the discussion needs to be revived

?ED       2004-05-21: Editors to add ednotes to the spec to 
                      indicate areas that had contention.  (Issue 

Issue 190 and editor note: proposal for links to any minority objections
from the status section for other votes
RESOLUTION: link to minority opinions from the status section
ACTION: people who want to file a minority opinion should do so by July

?ED       2004-05-27: Editors to add http:faultSerialization 
DONE      2004-06-10: Editors should correct issue 208, come 
                      back to WG if there are any questions.
DONE      2004-06-10: Editors should correct issue 213, come 
                      back to WG if there are any questions.
DONE      2004-06-10: Editors should correct issue 215, come 
                      back to WG if there are any questions.
?ED       2004-06-17: Editors to incorporate David Booth's clarification
                      in section 8.3 about what required means on MTOM
DONE      2004-06-24: Editors to incorporate Jonathan's resolution 
                      to issue 160. 
DONE      2004-06-24: Editors to fix media-type reg frag id link, 
                      per 209.
?ED       2004-07-01: Editors to add cross-references for component
                      properties, per DBooth's example.
DONE      2004-07-08: Editors to deal with issue 227, come back to 
                      the WG with issues if any.
?ED       2004-07-08: Editors to deal with issue 235, come back to 
                      the WG with issues if any.
DONE      2004-07-08: Editors to deal with issue 231, come back to 
                      the WG with issues if any.
DONE      2004-07-08: Editors to deal with issue 232, come back to 
                      the WG with issues if any.
DONE      2004-07-08: Editors to deal with issue 234, come back to 
                      the WG with issues if any.
?ED       2004-07-08: Editors to deal with issue 226, come back to 
                      the WG with issues if any.
?ED       2004-07-08: Editors to implement resolution to 177 as 

  (Part 3 component remains.)

DONE      2004-07-08: Editors to add f&p to Interface Fault, Binding 
                      Fault, and Fault References. (Issue 228)
PENDING   2004-07-08: Glen to verifiy composition model.
DONE      2004-07-08: Editors to add the optional AD feature to 
                      Part 2 (Issue 112).

  (note big changes!)

DONE [.2] 2004-07-08: Hugo to send email about AD feature setting 
                      HTTP header it shouldn't set.
DONE      2004-07-08: Part 2 editors to adopt MarkN's resolution for 
                      issue 230 (use {message label}).
DONE      2004-07-08: Editors to deal with issue 220, come back to 
                      the WG with issues if any.
DONE      2004-07-08: Editors to adopt Amy's proposal for Issue 233.

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0131.html

4.  Administrivia
  a. - August 2-4 (London)
       Logistics [.1], registration [.2].
     - September 14-16 (Toronto) [.3]
     - November (West Coast) 8-10 webMethods Sunnyvale, CA.
       Results of poll on moving to 9-11 [.4]

November F2F moved from 8-10 to 9-11
Paul: is there any logistics for Toronto?
Jonathan: I'll follow up with Arthur
* dbooth-fl (muted) logistics page is there but not yet announced or
updated with the changed dates.
* dbooth-fl I don't have a logistics page for September yet.

  b. XMLP WG response to our comments [.5, .6]


[.1] http://www.w3.org/2002/ws/desc/4/04-08-f2f.htm
[.2] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Mar/0064.html
[.3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004May/0000.html
[.4] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Jul/0008.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0036.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0006.html

5.  Task Force Status.
 a. Media type description
  - 1st Working Draft Published [.1]
  - Last Call Published [.2]
 c. QA & Testing
  - Suggested QA plan [.3]
  - More details from Arthur [.4]
  - Interop bake-off
 d. Schema versioning
  - Waiting to hear back from Schema on my draft "charter."
  - Henry's validate-twice write-up [.5]

[.1] http://www.w3.org/TR/2004/WD-xml-media-types-20040608/
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0052.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0037.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0019.html

6.  New Issues.  Issues list [.1].
  - Issue 239: Part 1 Editorial Issues (Asir) [.2]
      Already fixed!
  - Issue 240: input serialization flexibility (DaveO) [.3]
  - Issue 241: AD Feature: HTTP header conflicts (Hugo) [.4]
  - Issue 242: Binding accepts header and output serialization (Hugo)

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0110.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0073.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0131.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0005.html

All new issues are on the agenda

7.  Editorial issues:
  - Roberto's editorial comments [.1]
    If resolved, indicates closure of the following editorial issues:
    - 208 Misc. editorial comments 
    - 213 Refine component model property constraints 
    - 215 Clarify rule obviation
    - 220 Document interface extension semantics
    - 227 Description of Binding Operation component  
    - 231 Clarify "patterns" 
    - 232 Differentiate our MEPs from underlying protocol MEPs
    - 234 Ruleset terminology
  - Un-implemented editorial issues
    - 226 Cross-binding HTTP features
    - 235 Definition of Fault 
       {Sanjiva questions it}

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0210.html

Roberto sent comments about them:
Roberto:  conflict around safe property
Tom:      didn't we say that it could be neither true or false?
<sanjiva> +1 to Tom's recollection of this ..
Roberto:  that would be equivalent of false
<sanjiva> I also don't care that much but it seems consistent to say 
          that if the attr is not specified then "no info" is avail 
          about safety
<sanjiva> So this is a proposal to remove the default value.
Tom:      I thought that false meant *not* safe
Jonathan: is there any reason why we couldn't go with Roberto's
Sanjiva:  or we could remove the default value for safe
<pauld>   F2F discussion in Cannes: 
Roberto:  yes, but that's what the text says for 'false'
<pauld>   thinks it means "known to be safe" rather than "is safe"
David:    false means that the operation is not known to be safe
Jonathan: ok; there's still an issue of removing the default value
Tom:      based on this interpretation, then I'm withdrawing my
RESOLUTION: adopt Roberto's solution for safe

Discussion of item 2:
ACTION:   Editors to change styles from list to set.
RESOLUTION: change styles from a list to a set

Discussion of item 3:
RESOLUTION: make message label property required and make sure it 
          always has a value
ACTION:   Editors to make message label property required and make sure 
          it always has a value

Discussion of item 4 & 5:
Jonathan: is that a lot of editorial work?
Roberto:  no, it's pretty simple
RESOLUTION: accept item 4 & 5 from Roberto's proposal
ACTION: EDITORS to implement item 4 & 5 from Roberto's proposal

Jonathan: I propose to close all the issues marked as such in the agenda
(208 .. 234)
RESOLUTION: Close issue 208 .. 234 as listed in the agenda

Jonathan: 226 and 235 are still open

8.  Issue 168: Which operation [.1]
  - DBooth revived the thread at [.2]
  - Analysis at [.3]
  - Umit's proposal [.4]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x168
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0112.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0300.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0037.html

Jonathan: Originally, this issue looked editorial, and revived the 
          R114 discussion.  Last week, I was hoping to make some 
          progress, but it seems that we're back to the kind of 
          discussions we had in Cannes.  I have to apologize to the 
          WG for letting this issue get so big when we closed a 
          related issue.  How is this issue different from the one 
          we closed in Cannes?
David:    Which issue are you talking about?
Jonathan: It looks a lot like the original Operation Name Feature 
          Proposal.  It seems to me like it's reopening the issue,
          and we are having the same discussions.
David:    Are you saying that the proposals are similar to the ones 
          we heard in the past?
Jonathan: Yes, and in fact, the objections are the same.
Umit:     I disagree.  We now have 2 proposals, and we may be able 
          to solve R114
Jonathan: you are talking about Sanjiva's?  I haven't seen much
* alewis notes that r114 is already solved
* Roberto notes that it isn't
Umit:     Several organizations have expressed support for R114
Amy:      R114 is already met; it's about being able to, not 
          requiring, to unambiguously identify messages
Umit and Roberto: I disagree
<jeffsch> There does not appear to be WG consensus on the precise 
          meaning of R114
Jonathan: How is the proposal different from Cannes's Operation 
Umit:     In Cannes, there was a concrete proposal about how 
          things will look on the wire; the new proposal doesn't
Dbooth:   Wanted to point out that R114 would be a pointless 
          requirement with that interpretation
Glen:     Actually, I don't think it's that different; the intent 
          is the same; the intent is to say that ambiguous 
          descriptions are bad.
David:    I was hoping not to get into the meaning of R114
<mnot> +1 to dbooth's point
<jeffm> +1 from me
David:    There are two interpretations; the weaker one means that 
          it's a meaningless requirement: any WSDL author can write 
          an unambiguous document
<umit> clapping loud +1
<Roberto> +1
David:    I don't think it's productive to discuss R114 here
<jeffsch> s/meaningless requirement/clarification requirement/?
David:    The 2 previous proposals that were rejected were: unique 
          GED and Operation Name; but at the same time, the WG 
          reaffirmed the need to R114.  So I think we are 
          obligated to consider the proposals to meet R114
DaveO:    The folks who wanted unique GED didn't achieve victory.
<jeffm>   my +1 was to dbooth's statement that the weak interpretation 
          makes wsdl meaningless
<mnot>    as was mine
<jeffm>   wrt to interop
<jeffm>   sorry -- makes the req meaningless
DaveO:    People are saying that there must be some way to achieve 
          This. Somebody who voted no in Cannes is also likely to 
          vote no for the lesser requirement.  I don't think that 
          there is much support being gathered here.
Jeff:     I am sympathetic to the way Dave described the situation.
          Amy gave her of 6 different ways of doing this.  It's 
          just a situation inviting for profiling, and a statement 
          that W3C cannot make such a decision.  And maybe that's 
          the agenda of some people here.
* jeffsch doesn't believe that it's helpful to the WG process to 
          suggest that members have the agenda to thwart interop
<Glen2>   Thanks Dave
* Glen2   +1's jeffsch
Roberto:  I think that now we are not placing constraints on people 
          implementation anymore, but making sure that the wishes 
          of the author are preserved.
* Glen2   ...unless they have hard evidence! :)
<sanjiva> Jeff: can you precisely state how this prevents interop? 
          If my WSDL has enough stuff for you to send messages to 
          me, where does it cause interop problems? (Please 
          separate the case of using WSDL to define standard 
          interfaces .. in that case its certainly necessary to 
          indicate how messages are dispatched.)  I think that a 
          lot of people abstained, and are now ready to go for the 
          new proposals.
<dbooth>  There are (at least) two issues:
<dbooth>  1. Whether/how the wsdl:operation name is determined.  
          In particular: When a service *requires* its users to 
          support a particular mechanism for determining the 
          wsdloperation name in order to use that service, should 
          the WSD author be *required* to indicate that mechanism 
          as wsdl:required in the WSD?  
David:    There are a couple of other issues which crept in that 
          obscured this issue.
<dbooth>  Red herring: What is the name of the internal code (or 
          "operation") that the recipient will execute.
* alewis can't see that the presented issue *is* an issue, since the
mechanism is all in place.  what's the other issue?
David:    The issue is: who is being required? it's about requiring 
          the author to mark an extension as required to have the 
          feature required.
<jeffm>   IMO: this is fundamentally an argument about the centricity 
          (if you will) of wsdl for describing web services and 
          specifying the contract
<jeffm>   Its all about the client
Umit:     The point is what you must put in you WSDL so that your 
          client can communicate with you
<jeffm>   Its all about my being able to pick up a wsdl, and build a 
          client that interops.
<jeffm>   I thought this was all about not having to call the server 
          implementer on the phone, or sign an NDA in order to find out 
          how to use a service
Umit:     What is the requirement on the WSDL author?
<sanjiva> I have no problem with saying that the WSDL author must put 
          everything needed for the client to be able to send messages 
          and get the proper responses as the WSDL author intended. 
          However note that this is just a statement in the spec and 
          does not transfer to any concrete XMLism for us to define 
Glen:     I think it's correct that the WSDL needs to say everything 
          that's required for interaction.
<umit>    It does. If there is a mandatory operation, it is verifiable.
          Our job is to draw a line between [scribe missed] and 
<jeffsch> Sanjiva: Do you mean that *everything* must be in the WSDL? 
          How would we describe co-occurence constraints between 
          element children, for instance?
Glen:     You're going to do something to solve the problem.  It's 
          nice to have a marker to indicate that.  Although I don't 
          want to require unique GEDs, I think that it's a simple 
          mechanism to achieve this.
<sanjiva> There's clearly a line .. no semantics for example or the 
          order in which operations must be invoked. I'd like for the 
          WSDL to capture everything necessary for a single message;
          otherwise there is indeed an interop problem. 
Glen:     We could say that in the absence of any extensibility 
          indicating otherwise, you need unique GEDs.
DaveO:    Have you made that proposal?
Umit:     It's in my proposal
Sanjiva:  I understand the need to have a WSDL with enough information 
          to have [interop] to happen.  If WS-Addressing is required, 
          then it's my responsability to specify it.  No standard 
          extension is required here.
Glen:     [ explains the proposal ]
Jonathan: I'm still not convinced that it's a different issue from 
          the one in Cannes.
<sanjiva> Glen, is the proposed new abstract feature required?
Umit:     [ explains proposal ]
<jeffsch> Umit, do you understand that there is objection to the
          'requirement' for a 'mandatory' extension?  It is requiring 
          the author to add a mandatory extension if unique GED or 
          RPC are not used.
<sanjiva> I'm -1 to *any* mandatory features .. if we have some 
          mandatory thing then let's put it in the core component 
Jonathan: how about SOAPAction to accomodate that?
Umit:     SOAP 1.2 says it's optional. We would be requiring it.
Jeff:     Sanjiva, you say you agree with me at the abstract level, 
          but don't want to force anything concrete. This is what 
          the proposal is about.
<dbooth>  My understanding of Umit's proposal: If GEDs are NOT 
          unique, and not all operations are RPC style, then the WSD 
          MUST somehow indicate, as a wsdl:required extension, what 
          mechanism is required to determine the wsdl:operation name.
Jeff:     If you guys don't want to say what is required in the WSDL, 
          I don't understand why we're here
Sanjiva:  I'm not against saying that, but I'm against adding syntax
Umit:     I've already toned it down
<jeffsch> In some messaging paradigms, the operation name isn't part 
          of the agreement between the client and the service. Do 
          you agree?
Glen:     I'm having problems understanding if people don't want 
          the requirement or not.
* alewis  doesn't want the requirement.  a number of use cases 
          negotiate this out of band
David:    My understanding of Umit's proposal: If GEDs are NOT 
          unique, and not all operations are RPC style, then the 
          WSD MUST somehow indicate, as a wsdl:required extension, 
          what mechanism is required to determine the wsdl:operation 
          name.  It's not saying how to do that.
Glen:     You don't need to mention RPC is there
<sanjiva> I don't think we need to map it to a concrete value for 
          operation name. I think we should just say "The WSDL must 
          have enough stuff for the server to figure out what 
          message interaction the message is intended for." 
          There's absolutely no need to tie it to an operation 
<jeffm>   amy -- a use case that negotiates out of band is by 
          definition, non interoperable
Glen:     Second, I don't know how to interpret what you've just 
          said without a feature URI.
<alewis>  jeffm -- it is not, by definition, non-interoperable.  
          It may be using some other mechanism (a choreography 
          language, perhaps, or a policy/procedure language) to 
          communicate.  and it may do so interoperably.
David:    If you know what extensions you are using, then you know 
          if you have one that solves the problem
<jeffsch> jeffm: by interoperable, do you mean that each WSDL 
          processor can construct a semantically correct service 
          proxy and/or client stub?
<Roberto> "a WSDL document MUST indicate, as a required feature or 
          extension, the mechanism by which the wsdl:operation 
          component for a message can be determined"
JeffSch:  We have done a lot of work in the WG to implement basic 
          message paradigms.  My concern is that there are message
          paradigms other than RPC for which such a requirement 
          wouldn't be appropriate or reasonable.
<dbooth>  But JeffS, nobody *requires* you to write your WSD using 
          multiple operations.  If you are doing so, then presumably 
          they are significant.
Umit:     QNames are used for other paradigms
<jeffm>   amy- the use case u describe is using a different language, 
          WSDL, to describe a web service - no?
JeffSch:  in some cases, you don't want to do that
Umit:     in which case, you need additional headers, etc.
<jeffm>   that's fine -- i bet i can come up with a CORBA IDL-> 
          WSDL/SOAP binding, and it will be interoperable for people 
          using that CORBA IDL
<jeffm>   but its not WSDL
Umit:     And then you use an extension
<jeffm>   In fact - -that excercise was done many years ago
JeffSch:  Not always, they could be depending on the value of certain 
          fields.  It turns out that none of the mechanisms we have 
          today allow us to describe these situations
<alewis>  jeffm -- and your point is?  wsdl is not used in a vacuum; 
          it is, in the particular use cases that I am concerned about,
          being used to update legacy systems.  there is a limit to 
          the flexibility of these systems.
<dbooth>  q+ to point out to JeffS that nobody *requires* you to 
          write your WSD using multiple operations.  If you are saying 
          that they are not significant, then why use them?  If you 
          wish to use data values to determine the operation name, 
          then Umit's proposal would merely require you to *indicate* 
          that fact in the WSD -- it would not preclude it.
Umit:     By requiring such an extension, you will prevent certain 
          situations to be described.
Jonathan: Umit has a modified proposal
<alewis>  jeffm -- and it happens that a variety of tools are used 
          to complement the information provided in the wsdl, in 
          order to enable these cases.  eventually, things may get 
          cleaner, but in order to enable the transition, the 
          ability to describe things, even if incompletely, is 
<dbooth>  My v2 understanding of Umit's proposal: If GEDs are NOT 
          unique, then the WSD MUST somehow indicate, as a 
          wsdl:required extension, what mechanism is required to 
          determine the wsdl:operation name.
Jonathan: I still don't see how it is different from the one in 
          Cannes, but at the risk of generating more minority 
          opinions, I will put it up for a vote. I will skip a 
          straw poll as we clearly won't reach consensus.
<Glen2>   as a wsdl:required extension or a required feature
* dbooth  has been hearing progress fwiw, but defers to the 
          chair's judgement
<Roberto> and "wsdl:operation name" means "identifying a wsdl 
          Interface Operation component"
<dbooth>  My v3: understanding of Umit's proposal: If GEDs are 
          NOT unique, then the WSD MUST somehow indicate, as 
          a mandatory extension, what mechanism is required to 
          determine the interface operation component.
<sanjiva> clarification: is this just text in the spec?? 
<DaveO>   this is the same vote as in cannes...
Yes: Lexmark, Rogue Wave, Sun Microsystems, Sonic Software, 
     British Telecommunications, W3C, Macromedia, Oracle, 
No:  SeeBeyond, TIBCO, Cyclone Commerce, BEA Systems, 
Abstain: IBM
Results:  10 Yes - 5 No
Jonathan: Anybody would like to file a minority opinion?
TIBCO and Microsoft may

[Minutes record this: "RESOLUTION: issue 168 closed with proposal 
v3" but chair thinks this is incorrect given the following AIs.]

ACTION: Editors to incorporate Operation Name proposal v3
ACTION: DBooth to send email to Mark Baker about issue 168

9.  webMethod issues:
  - Issue 229: useOperationWebMethod proposal [.1]
  - DaveO's proposal [.2]
  - Issue 169: Syntax for webMethod - property or attribute? [.3]
  - Proposal [.4]
  - Atom WSDL binding example [.5]
  - Sanjiva's counterproposal (?) [.6]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x229
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0288.html
[.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x169
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0060.html
[.5] http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0157.html

DaveO:   [ introduces
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0288.html ]
DaveO:   the crux of the discussion is about it belongs at the 
         abstract level.  There were also discussions around which 
         verbs to use; I proposed the HTTP verbs, and I don't think 
         that it's the heart of the issue.
Sanjiva: You said that this information helps the binding author.
         Does it have an impact on the client?
DaveO:   I think it may impact dispatch
Roberto: I still don't understand what they mean at the abstract 
DaveO:   [ scribe missed ]  Something like the operation safety would 
         become duplicate information, and I'd like to get rid of 
Roberto: in the case of safety, we can get an abstract definition; 
         for POST, it's harder
Hugo:    I would like to voice support for this proposal; the 
         abstract level is the right place, e.g. to have toolkits 
         use the right settings for bindings supporting the method 
         advertized; I have made a proposal for meaning of the verbs 
         that wasn't rejected AFAICT; I don't think that safety should 
         be removed, as if the semantics of GET don't apply, then I  
         wouldn't be able to say that my operation is safe
Mark:    PROPFIND is safe too
Jonathan: are we fine with this proposal?
<Roberto> does the proposal make the webMethod attribute extensible?
Sanjiva: I believe it belongs in the HTTP namespaces
<mnot>   +1
DaveO:   I don't consider this as a friendly ammendment
Umit:    [ scribe missed the question ]
DaveO:   In the case of Atom, they know they're using HTTP, there is 
         no formalization. My proposal to use the operation name was 
         (strongly) rejected.  Atom has 10 different kinds of GET.
         I would be worried to be using the whttp namespace at the 
         abstract level, as people will consider it weird and 
         wouldn't use it.  We can call that genericMethod, but leave 
         it in the WSDL ns.
Jonathan: I'd like to extend by 20 minutes
<jeffm>  i have to leave now
<jeffm>  i wonder if we will have critical mass to make decisions
Sanjiva: I haven't seen a proposal to describe why GET, PUT, POST, 
         DELETE mean
<Marsh>  That't why I'm hoping to deal with more trivial items....
* asir   Okay DaveO, I leave my proxy with Hugo
<jeffm>  Trivial is in the eye of the beholder
Amy:     same comment
Hugo:    I have made such a proposal
Amy:     I have read your email, it's a nice effort, but it's still 
         HTTP, it's not generic
POLL = Support for DaveO's proposal:
Results: 6 Yes 5 Nos
Jonathan: Any objection?
Umit: Yes
Jonathan: Objection to rejecting the proposal?
Mark, DaveO: Yes
Jonathan: I'll do the vote next week

10. Issue 189: Binding message content to URI [.1]
  - Issue details from DaveO [.2]
    - Omitting content
    - Attributes
    - QNames
  - ATOM WSDL example [.3]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x189
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0061.html
[.3] http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20

Jonathan: I would like a more concrete proposal
DaveO:    I haven't seen any discussion
Sanjiva:  I don't like that
Amy?:     same here
Hugo:     I like URI construction for other things, but I'm afraid 
          about the complexity.  Attributes and QNames seem complex 
          to me.


11. Issue 130: Need async request/response HTTP binding [.1]
  - WG in favor of adding such a MEP, with some expressing a desire
    that this be as lightweight as possible.
  - Revived proposal from DaveO [.2]
  - Sanjiva's alternative [.3]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x130
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0287.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0040.html

12. Issue 211: Omit interface message in binding? [.1]
  - Mark's proposal [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x211
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0047.html

Mark:    This is pretty much plugging a hole in the spec
RESOLUTION: issue 211 closed by adopting Mark's proposal
ACTION: Editors to implement

13. Issue 236: MTOM/XOP support [.1]
  - Details (Umit) [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x236
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0038.html

RESOLUTION: Close issue 236 by adopting Umit's proposal
ACTION: Editors to implement

14. Issue 237: Editorial issues with Part 3 [.1]
  - Details (Hugo) [.2]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x237
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0011.html

ACTION: Hugo to clarify the second part of the proposal (readibility)
ACTION: Paul to research the fault decisions we've taken
ACTION: Editors to implement
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0011.html except
for faults and SOAP binding readability problem

15. Issue 238: Consistent placement of <feature> and <property> [.1]
  - Details (Sanjiva) [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x238
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0267.html

Sanjiva:  they're not consistently at the end
Roberto:  I think they are.  They should be at the end
Jonathan: we need to clarify this
ACTION:   Roberto to check if <feature> and <property> placement in
          the infoset representation prose is consistent with the schema

16. Issue 239: Part 1 Editorial Issues [.1]
  - Details (Asir) [.2]
  - Already implemented.

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x239
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0110.html

Jonathan: it's been fixed already; any objections?
RESOLUTION: issue 239 closed

17. Issue 240: input serialization flexibility [.1]
  - Details (DaveO) [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x239
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0073.html

Jonathan: the WG did agree to allow some text like proposed to go
          it.  Any objection to David's wording?
RESOLUTION: issue 240 closed by adopting DaveO's wording
ACTION: Editor to include DaveO's wording:

18. Issue 241: AD Feature: HTTP header conflicts [.1]
  - Details (Hugo) [.2]
  - Roberto's suggestions [.3]
  - Consensus on "say that it is an error if the HTTP stack finds itself
having to override an AD-specified header"?

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x240
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0131.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0148.html

Jonathan: the proposal that seemed to carry support was to have an 
          error in case of conflict
RESOLUTION: issue 241 closed by raising error in case of conflict
ACTION: Editors to indicate error for AD HTTP binding in case of

19. Next steps
  - Closing issues list on Parts 1, 2, 3 except to editorial issues.
  - Last Call Schedule:
    - July 22nd (90 min telcon):
        Editors complete editorial work for WG review.
        Disposition of any outstanding editorial issues
    - July 29th (short telcon):
        Approval of Last Call drafts.
    - Aug 3rd WSDL 2.0 Last Call publication.


Received on Thursday, 22 July 2004 14:58:33 UTC