- From: David Booth <dbooth@w3.org>
- Date: Fri, 16 Jul 2004 15:51:33 -0400
- 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
>
>Present:
> 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.
>
>Regrets:
> 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
>
>--------------------------------------------------------------------
>Agenda
>
>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
>22
>
>?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]
>
>Postponed.
>
>[.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
>[.3]
>http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/att-0029/QA_Oper
>ational_Checklist.htm
>[.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)
>[.5]
>
>[.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
>Agenda:
>http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0238.html
>
>------------------------------------------------------------------
>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:
>http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0210.html
>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
>solution?
>Sanjiva: or we could remove the default value for safe
><pauld> F2F discussion in Cannes:
>
>http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0038.html
>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
>objection
>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:
>http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0288.html
>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
><Marsh>
>http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0047.html
>Hugo: I like URI construction for other things, but I'm afraid
> about the complexity. Attributes and QNames seem complex
> to me.
>
>Postponed.
>
>------------------------------------------------------------------
>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
>
>Considering
>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
>http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0047.html
>
>------------------------------------------------------------------
>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
>http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0011.html
>
>------------------------------------------------------------------
>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:
>http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0073.html
>
>------------------------------------------------------------------
>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
>conflict
>
>------------------------------------------------------------------
>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.
>
>ADJOURNED
--
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Friday, 16 July 2004 15:51:38 UTC