- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 16 Nov 2004 12:47:54 -0800
- To: <www-ws-desc@w3.org>
Web Service Description Working Group
Minutes, FTF meeting 10 November 2004
Sunnyvale, hosted by webMethods
Agenda:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0023.html
Attendence:
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Youenn Fablet Canon
Hugo Haas W3C
Anish Karmarkar Oracle
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Arthur Ryman IBM
Jerry Thrasher Lexmark (afternoon)
Asir Vedamuthu webMethods
Sanjiva Weerawarana IBM
Umit Yalcinalp SAP
Prasad Yendluri webMethods, Inc.
Phone:
Paul Downey British Telecommunications
Jean-Jacques Moreau Canon
David Orchard BEA Systems
Regrets:
Tom Jordahl Macromedia
Dale Moberg Cyclone Commerce
Mark Nottingham BEA Systems
Bijan Parsia University of Maryland MIND Lab
-------------------------------------------------------
Wednesday 10 November
-------------------------------------------------------
Scribe: Youenn
09:00 SOAP 1.1 Binding
- First draft [35]
- Modified Part 3 (aka, added soap version) [36]
- Modified XML Schema for SOAP in WSDL 2.0 [37]
[35]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-soap11-bi
nding.html?content-type=text/html;%20charset=utf-8
[36]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/mod-wsdl20-bindi
ngs.html?content-type=text/html;%20charset=utf-8
[37]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/mod-wsdl20-soap.
xsd
Presentation by Asir
Asir explains changes made to the spec to make the soap version works
Asir: Added the soap:version @ and changed the value of type. Now
it is soap (previously was soap12). New section 2.4 to
describe soap:version
Jonathan: We do not have default schema values for attributes in the
rest of the spec and there is a default 1.2 value for
soap:version
Asir: Should move the default value in section 2.4.4.
RESOLUTION: Move the default attribute value in section 2.4.4 to the
mapping rule table.
Asir: Remove all direct ref to soap12 and introduce a new section
Section 2.10: soap1.2 binding. Section 2.10.3 defines the
defaulting rules for soap1.2 binding (soap action...)
Sanjiva: We had some text for the supported wsdl mep in the soap1.2
binding. We do not say anywhere which wsdl meps are supported
Asir: To be added in the text. Same should be true with soap1.1.
We could claim that either at the soap binding level or both
at soap1.2 and soap1.1 binding level
RESOLUTION: Add text indicating which MEPs are supported by the SOAP 1.2
and SOAP 1.1 bindings.
Presentation of the schema
Hugo: How have you abstracted soap modules from soap12?
Asir: It is in section 2.7. Removed all direct reference to
soap1.2, otherwise it is the same
Hugo: We should define it because we are extracting modules from
soap12 to apply it on soap11. This section might not make
sense for somebody that did not know anything about soap12
Glen: Since it is only a concept, no problem applying it in soap11
Asir: Section 2.7.1 should reference to the soap12 rec. soap11
binding is a very small spec. Introduce new names: one for
the http binding, one for the req-resp mep and one for the
one_way mep
Sanjiva: What does feature name means in soap11? If these are the
only features that are defined, we should remove ref to
security, reliability, etc. Tthese things should be modules
in the binding, we identify the soap11 binding using the
version @
Asir: The term soap module is defined for soap11. Section 3.3
defines default binding rules when version is 1.1
Asir describes soap action, soap mep selection and http method
selection default rules
Anish: No value for soap action should map to ""
Jonathan: what about soap fault subcodes
Asir: One way is to remove it from soap binding and put it in the
soap 1.2. The other way is to ignore them when using soap11
Sanjiva: The latter option is better
[Anish: SOAPACTION HTTP header field for SOAP 1.1 --
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383528]
Asir: Add to the text the "ignore fault codes and subcodes for
soap11" rule
RESOLUTION: Add to the text the "ignore fault codes and subcodes for
soap 1.1
Sanjiva: In soap11 spec, there is no definition of a soap11
request-response
RESOLUTION: Drop the soap11 mep ref in section 3.3
Sanjiva: We should ignore the soap mep value whe using soap 11 binding
and remove the SOAP mep selection text, and the same should
apply for the http method selection. http method is always
http post. http method value should also be ignored
RESOLUTION: remove the http method selection and soap mep selection
rules
Anish: When using the soap one way mep, you cannot return a soap
envelope. The http response must be empty (quoted from BP)
[Anish: bp 1.1 --
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#One-Way_Op
erations]
Hugo: We are working on soap11 binding for backward compatibility
only.
discussions on supporting soap11 one way mep
Umit: A lot of ws-i work is bug fixes. We should refer to that work
Jonathan: These bug fixes are only valid for the basic profile
Anish: We should fill the holes of wsdl11 soap11 binding
Sanjiva clarifies the proposal
Sanjiva: Which wsdl meps are bound to the soap11 binding? only in-out
and in-only
Asir: First proposal is soap mep should be ignored in the wsdl
soap11 binding
discussions now about http binding supporting out-in wsdl mep
Sanjiva: The proposal is that we support in-out and in-only
[Hugo: Decision about the HTTP binding:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0066.html]
Sanjiva: If the wsdl mep is in-only, the http response is undefined
but should be empty if following the basic profile
Jonathan: The purpose of using the wsdl soap11 binding is to migrate
a service from wsdl11 to wsdl2 without having to fix the
service/server implementation/configuration
discussions on the scope and purpose of the soap11 binding
discussions on whether refering to ws-i bp from the wsdl soap11 binding
or not
Jonathan: Add a non normative reference to bp within the wsdl soap11
binding spec explaining how in-only wsdl mep maps to soap11
over HTTP
RESOLUTION: add a non-normative reference to BP within the soap 1.1
binding
spec as explanation of how in-only WSDL MEP maps to soap 1.1
over
HTTP.
ISSUE: make sure in-only mep is supported in wsdl soap12 binding
Hugo: Soap modules are identified by uris. We should say in the
spec that soap11 module authors should identify their module
with a uri
RESOLUTION: Add text in section 3.2 that soap modules in 11 are adopted
from SOAP12 and then soap11 modules need to have a uri.
RESOLUTION: drop SOAP feature in 11 binding and define one URI for
SOAP11
HTTP binding
Hugo: We should say that this binding is for backward compatibility
as
per the charter
RESOLUTION: add mention info from charter to soap11 intro
Glen: I do not want our spec to require support the soap11 binding
if supporting the soap12 binding
Jonathan: It is then clearer to have the soap11 binding as a note
Hugo: The charter says that soap11 binding will be a note. If we
want
to change this, we should ammend the charter. If we follow
the
REC track for soap11 binding, this raises the bar. It is
simpler
to keep it as a note
Strwapoll:
2 for pursuing folding the SOAP11 binding into the spec,
12 against
Consensus to adopt Asir proposal as a working draft
Consensus to adopt Asir part3 changes to accommodate the soap11 binding
ACTION: Asir to implement resolutions adopted at this FTF.
ACTION: Part 3 Editors to roll in Asir's changes.
Jonathan: We should then publish the drafts after making the changes in
the specs.
10:40 Break ----------------------------------------
--------------------------------------------------------
11:10 Fault Component placement
- Issue LC19: Fault Component Re-usable Across Interfaces [12]
+ Asir detailed binding changes [13]
- Issue LC75a: WSDL 2.0 LC Comments (a) [14]
[12] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC19
[13] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0057.html
[14] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75a
Umit: We should allow override the reason of exception in different
operations.
Roberto: Is this discussion about overriding the reason of a fault or
also the code at the operation level
Glen: Should code and subcode be changeable? No. The code is meant
to define the fault type in soap.
Umit: The same exception can be raised for two different reasons
Roberto: The code is similar to the type of the exception in java
Glen: We should be able to add soap modules to soap faults because
these are also messages
Roberto: The fault instance will have the same detail data type but
not the same detail data
Asir: For the same geds, we can have multiple faults with different
fault codes
Umit: The question may be whether to set the reason of the fault if
we know it in advance
Glen: We could create a new fault or have a fault detail with a
choice in it. Reason is totally runtime and we should not
have a means to set it in wsdl
Sanjiva: It is realistic to have several operations of an interface
sending the same fault.
discussions about Asir proposal to promote faults as top elements
Roberto: Interface inheritance is usable to reuse faults within
interfaces
First question to answer is whether to promote faults at the top level
Asir: Fault components are not globally reusable
Sanjiva: Fault has a concept which is more than an element
discussion on using interfaces inheritance for enabling fault reuse
Roberto: It is easier to have them in the interface than to have them
global. If global, you would need to go through all
operations and dereference the referenced faults
Sanjiva: If we allow top level faults, it would be natural to bind
the faults independently
Asir: This is the second level of reusability. The first level is
reuse at the abstract level and the other at the binding level
Sanjiva: If we do not do both, then the solution will be half baked.
We should do both or keep them at the interface level
Asir: This is difficult at the binding level
Sanjiva: Then it is half baked
[pauld: jeff says fault references are the same as messageRef, why
don't the reuse issues (which abstract faults attempted to
resolve) apply to messages?]
Sanjiva: If we promote faults at the top level, we should allow binding
them at the top level also which is very costly
[pauld: Notes hyperdictionary.com says "half-baked" means "a screwball
proposal without a prayer of working" ..]
Umit: Why do we need to bind faults at the top level?
[pauld: it was in sunnyvale one year ago!]
[pauld:
http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0059.html]
[pauld: and JeffSch was there!]
[GlenD: :)]
[Sanjiva: paul, was webmethods there too? ;-)]
[pauld: lilly and prasad :-)]
[GlenD: As the originator of the pull-up proposal in the first place,
Paul, what do you think of this?]
Asir: For the generation case, reusability at the abstract level is
sufficient
[GlenD: Leave them in the iface, or pull them up further?]
Strawpoll: Lift abstract faults at the top level or leave them at the
interface level?
3 for option 1
6 for option 2
Jonathan: Can we live with the status quo ?
no objection to close issue LC19
RESOLUTION: Issue LC19 closed without action.
TOPIC: Issue LC75A
Sanjiva: In the code to wsdl generation case, it is natural to have an
interface with operations that share the same exceptions
[pauld: basically saying i'm divided in opinion - i agreed with much
of what jeff said in his email, in particular what's special
about faults? - esp when describing an exisitng message
exchange bottom-up (tooling could have a problem abstracting
the faults). but when writing WSDL first top down, abstract
faults (and even hoisting them even higher) has great merit
IMO. so i'm divided between jeff and Asir's proposals and
therefore chickened out and abstained.]
Sanjiva: Sharing of faults is a common case
Jonathan: Any objection to close 75a with no action ?
consensus to reject LC75a
RESOLUTION: Issue LC75a closed without action.
ACTION: Sanjiva to write the rationale for rejecting LC75a
--------------------------------------------------------
12:00 SOAP binding
- Issue LC55: binding/operation/infault|outfault? [38]
- Issue LC56: Clarification for binding fault [39]
- Issue LC61d: comments on the wsdl 2.0 working drafts (d) [40]
[38] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC55
[39] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC56
[40] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC61d
Jonathan: Issue LC55, LC56, LC61d appear to be essentially duplicates
Glen: Good if we can bind infault or outfault like saying use
this encryption module when sending this fault. If I can
put a module for an input, I should be able to put it for
an infault|outfault on a per operation basis without having
to rewrite a module
Sanjiva: We made this design on an 80/20 case
Roberto: It seems strange to not have infault and outfault in the spec
Jonathan: We should maybe add a rationale in the spec
Roberto: it would look like input and output at the binding level
<infault ref="fault qname">
<documentation/>
<wsoap:module/>
<feature/>
<property/>
</infault>]
Sanjiva: We could add infault and outfault and restrain them to include
only soap:module and extensions, not set the code and subcode
Glen: Sounds right
ACTION: Roberto to write up the addition of infault and outfault at
the
binding level plus modifications at the component model.
12:15 Lunch ----------------------------------------
Scribe: Arthur
--------------------------------------------------------
13:15 January F2F Planning
Jonathan: is proposing January 24 in Melbourne to co-locate with
WS-Addressing.
Sanjiva: objects on the date since the gap until the next meeting is
too short
Jonathan: says there will be a 5-week period until our following
meeting:
March 3-4
Jonathan: has requested March 3-4, to be confirmed
Sanjiva prefers an earlier date
Jonathan: Is Jan 10 better?
Roberto: Prefers Jan 24
Jonathan: Jan 13-14?
[Week of the 17th appears to be preferable to those in attendance.]
[dorchard: btw, I will not be attending a Jan 13-14th WSDL meeting in
Australia. Who is the host?]
[Roberto: BEA]
[dorchard: When did BEA offer to host on Jan 13-14th?]
[Sanjiva: DaveO: We decided to ask BEA to resched to Jan13-14th as
that was the preferred wg position]
[Roberto: I don't think you did. simply, the wsd wg would prefer that
date.]
13:30 Formal Objections recap
- Features and Properties [46]
+ Glen's presentation to CC Workshop [47]
- Lack of compositors [48]
+ Issue LC59f: WSDL2.0 Last Call comments (f) [49]
- Unique GEDs [50]
[46] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0375.html
[47] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0060.html
[48] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0371.html
[49] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC59f
[50] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0376.html
Glen: Recap - IBM, Microsoft, SAP object to F & P. Sonic, IONA,
Oracle, Sun object to lack of compositors.
Glen: Proposes to put F&P into Part 2. In exchange, add compositors
to F&P. Simplify proposal for compositors based on Cannes
suggestions. F&P is very similar to WS-Policy. Motivation is
to motivate spec writers to identify important parts of spec
Anish: Glen, is your proposal atomic
Glen: It's a compromise
Sanjiva: WS-Policy is more generally useful than WSDL. If F&P is in a
separate extension, does that imply it is more generally
useful?
Glen: Nothing prevents anyone from using elements from the WSDL
namespace more generally. The main point is that it is a
pre-defined extension, not that it has its own namespace
Jonathan: F&P is essentially optional, aside from encountering required
ones. The benefits of putting it in an extension are minimal
since if you don't want to support F&P you just have to fail
when you encounter a required one.
Kevin: Users will have to chose between Ws-Policy and F&P
Glen: I hope W3C creates a standard in this space
Asir: Such a W3C WG may never get formed
[Anish: c&c workshop -- http://www.w3.org/2004/09/ws-cc-program]
Asir: The C&C workshop did not agree to form a WG
Sanjiva: The C&C conclusions do not reference F&P
Jonathan: We discussed the comprise, next step is to see if it is
acceptable
Glen: Sonic supports the comprise. The compositor proposal will be
simpler than the original
Asir: We need to see the simplification
Glen: I request a straw poll to see if this is a reasonable proposal
Asir: How simple is the compositor
Glen: And, Or, Not. Nested compositors is included
Sanjiva: You need to define equivalence rules of boolean compositions,
etc.
Jonathan: Do the simplified compositors satisfy the objectors
[pauld: original proposal for compositors:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0153.html]
Glen: Let's at least decide that this is a good direction to move in
with the aim of removing the objections.
Jonathan: Since IONA and Microsoft are absent we can't decide.
Glen: We have IBM, Oracle, Sun, SAP.
Sanjiva: I need to review this proposal at IBM. IMHO, we should make
this
work in the context of SOAP modules and not have an abstract
F&P
solution. E.g. if we need compositors for SOAP modules, then
we
should add them. Moving F&P to Part 2 doesn't make much of a
practical difference.
Kevin: I need to go back to SAP to discuss it.
Roberto: I disagree that this just needs to work in the SOAP context
since
it is useful for other protocols. I think this is a good
compromise.
Anish: Oracle would like to see this in the main spec, but this is a
good compromise. I would like to hear the responses from the
other companies.
Jonathan: From the Microsoft viewpoint, this does not seem like a
beneficial
compromise since compositors add a lot but moving the
functionality
from part 1 to 2 doesn't change very much in practice.
[pauld: I have to applaud Glen's attempt to achieve consensus, but
worry deeply about how complex the WSD spec is as it stands.
Adding compositors even as an 'extension' could be 'jumping
the shark', IMO.]
Jonathan: What is the evolvability story? How will F&P come together
with WS-Policy?
Sanjiva: Is Ws-Policy was submitted to W3C would you remove F&P?
Glen: No, because it would take too much time. It's important that
stable names/identifiers get assigned to specs so that spec
writers can refer to them.
Hugo: Question: Are you saying that the simplified proposal would
be developed quickly enough for WSDL 2.0?
[pauld: Suspects that if ws-policy was submitted tomorrow and followed
the anticipated ws-addressing track, it could still be a rec
before WSDL :-(]
Roberto: There is a good start on the proposal which was submitted 6
months ago. I objected to the process followed. Adequate
consideration was not given.
Glen: To answer Hugo, I estimate 1 month.
Jonathan: We need to get a brief sketch of the compositor proposal.
ACTION: Glen will post an e-mail describing the proposal.
Topic: Unique GED Objection
[DBooth: http://www.w3.org/2004/Talks/1110-DBooth-opname/]
DBooth now is presenting the proposal at the given URL
IBM. Microsoft, TIBCO filed the objection
Slide 8: Only DBooth interprets the spec wrt to the client requirement
Slide 10: Sanjiva objects to point 5 since client and service use
different
toolkits. DBooth asserts that Sanjiva is describing a
different
scenario.
DBooth recommends on slide 12 to augment the spec
ACTION: DBooth will produce text for the spec
15:25 Break ----------------------------------------
--------------------------------------------------------
16:00 Unique GED Objection (cont.)
[Roberto: on slide 15, "no verb" = POST]
DBooth presents recommendation on slide 22
DBooth: Slide 25 summary
DBooth: End of presentation
Jonathan: How does this address the objection?
DBooth: The current wording in the spec needs to be modified
ACTION: Editor remove ambiguity if it exists
ACTION: Jonathan to create 3 new issues from slide 25 on points 1, 2,
and 4
Sanjiva: is presenting thoughts on the granularity issue, moving the
requirement down to the message level to enable service to
distinguish, e.g., between multiple inputs of the same GED
Jonathan: You are asserting that Web services deal with verb+message,
not message, and that operations, interfaces, etc. are just
convenient ways to group them
Glen: The tuple (service, operation, message) needs to be conveyed.
Convey does not mean literally transmit
Sanjiva: Proposes a solution: add an {opcode} property to
MessageReference component, define an algorithm for a
default, allow user to set, must be unique across an interface
Anish: The {opcode} should be unique across all interfaces.
Sanjiva: Now define this at the binding, i.e. SOAP 1.2
ACTION: Sanjiva will write up this proposal and email it to the list
as a response to the objection
17:15 Adjourn
Received on Tuesday, 16 November 2004 20:48:24 UTC