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

Re: Minutes, 15 July 2004 WS Desc telcon

From: David Booth <dbooth@w3.org>
Date: Fri, 16 Jul 2004 15:51:33 -0400
Message-Id: <>
To: "Jonathan Marsh" <jmarsh@microsoft.com>, <www-ws-desc@w3.org>

Minor corrections resulting from having an ambiguous first name: :)

s/Support for David's proposal/Support for DaveO's proposal/
s/Mark, David: Yes/Mark, DaveO: Yes/

At 03:58 PM 7/15/2004 -0700, Jonathan Marsh wrote:

>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
>                       190)
>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
>                       attribute.
>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
>                       feature.
>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
>                       amended.
>   (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]
>  b. MTOM/XOP
>   - 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
>           Support.
>* 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
>           Name?
>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
>           now.
>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
>           extensions.
><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
>           model.
>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
>           name.
><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
>           crucial.
><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,
>      webMethods
>No:  SeeBeyond, TIBCO, Cyclone Commerce, BEA Systems,
>      Microsoft
>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
>          level
>DaveO:   [ scribe missed ]  Something like the operation safety would
>          become duplicate information, and I'd like to get rid of
>          it
>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 David's proposal:
>Results: 6 Yes 5 Nos
>Jonathan: Any objection?
>Umit: Yes
>Jonathan: Objection to rejecting the proposal?
>Mark, David: 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.

David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Friday, 16 July 2004 15:51:38 UTC

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