- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 29 Sep 2003 17:08:52 -0700
- To: <www-ws-desc@w3.org>
Web Service Description Group
Minutes, FTF meeting 22-24 Sept 2003
Palo Alto, hosted by SAP.
--------------------------------------------------------
Monday 22 September
--------------------------------------------------------
Present:
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Steve Graham Global Grid Forum
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Philippe Le Hégaret W3C
Kevin Canyang Liu SAP
Lily Liu webMethods
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Jeffrey Schlimmer Microsoft
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Phone:
Amelia Lewis TIBCO
Jean-Jacques Moreau Canon
Regrets:
Youenn Fablet Canon
Steve Lind AT&T
Ingo Melzer DaimlerChrysler
Adi Sakala IONA Technologies
Agenda [0]
[0] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0140.html
--------------------------------------------------------
Scribe: Jeff Mischkinsky
09:00 Introductions and logistics
- Assignment of scribes:
Umit Yalcinalp (Wed), Jeff Mischkinsky (Mon AM), William Vambenepe
(Tue AM), Tom Jordahl (Mon PM), Philippe Le Hégaret (Tue PM),
Lily Liu, Jacek Kopecky
Logistics [1], dial-in numbers [2] (members only).
[1] http://www.w3.org/2002/ws/arch/3/07/f2fSeptLogistics.html
[2] http://www.w3.org/2002/ws/arch/3/07/f2fSeptLogistics.html#Bridge
--------------------------------------------------------
09:15 Removing message. New Draft [3], schema [4]
- Countdown to close the following issues [5].
* Issue 27: Remove 'style' attribute [6]
* Issue 39: Binding extensions depend on structure of
portType [7]
* Issue 40: Binding extensions for SOAP interact in a
complex way [8]
* Issue 45: fault/@use should be optional [9]
* Issue 48: soap:body/@use should be optional [10]
* Issue 63: soap binding violates separation of abstract
and concrete [11]
[3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml
[4] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xsd
[5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Aug/0004.html
[6] http://tinyurl.com/mwuy#x27
[7] http://tinyurl.com/mwuy#x39
[8] http://tinyurl.com/mwuy#x40
[9] http://tinyurl.com/mwuy#x45
[10] http://tinyurl.com/mwuy#x48
[11] http://tinyurl.com/mwuy#x63
Marsh: Objections to closing 27, 39, 40, 45, 48, 63 - going once,
going twice, ... SOLD ... They are now closed.
RESOLVED: Issues 27, 39, 40, 45, 48, 63 are closed.
--------------------------------------------------------
- Rules for @encodingStyle [12, slide 18]
* No default value
* If not given then no information about the "style" of
the operation's elements is available.
A proposal was floated to rename to encodingStyle to style to differentiate
it from the SOAP encoding.
RESOLVED: Consensus to add attribute named style -- no default
--------------------------------------------------------
- @encodingStyle="http://www.w3.org/2003/ws/desc/rpc" [12, slide 19]
* The input and output elements have been defined according to
a pattern indicated by these rules.
* Input/output elements contain only local element children
(i.e., no global elements allowed). (No <choice> etc.
allowed? Not sure but probably should say so.)
* Input element's name's localPart and operation/@name are the
same.
* Output element's name's localPart is
concat(operation/@name,"Response")
* Input and output elements are both in the same namespace.
* The child elements of input and output represent input and
output parameters of the operation. ("<part>" in WSDL 1.1)
* If there exists foo such that there are child elements named
foo in both input and output elements, then that represents
an in/out parameter.
* If there does not exist any such foo in both elements then
all the parameters are input-only and/or output-only as
appropriate (depending on whether they're in the input or
output element).
Discussion of whether to have extensibility point
[TomJ: Except when we are using "RPC", which is currently the only
thing we expect to be put there]
Make clear not required.
[Roberto: wsdl:rpcStyle="true"]
Straw poll - boolean flag for using rpc rules or uri?
non recorded results - boolean: 4, uri: 9, abstain: 2
Discussion on wording in spec on what is going to be required if the uri is present.
[sgg: 6.1.1 of the current editor's draft of part 1 states:]
[sgg: Mandatory extensions are those that MUST be processed correctly by the WSDL processor. If a mandatory extension element is processed, the WSDL processor MUST either agree to fully abide by all the rules and semantics signaled by the extension element's qualified name, or immediate cease processing (fault). ]
[sgg: note: it doesn't state that the processor can simply "stop processing" a single component]
ACTION: sanjiva to clarify wording on op style to say that use of uri is assertion on part of author and if the schema doesn't match then it is an error.
--------------------------------------------------------
TOPIC: specific rules for style='.... rpc'
2nd bullet: why no global elements?
Proposal to add another bullet: First param if it is out-only is result
Restate: if the first param in the result message is an out-only then it is the return, otherwise there is no return value
Going once, going twice --- SOLD good enough for publication next week.
RESOLVED: Add another RPC style rule: "If the first param in the result
message is an out-only then it is the return, otherwise there is
no return value.
Proposal: restrict these rules to XML Schema only and its a sequence
RESOLVED: Restrict these rules to XML Schema only and model as a sequence
Umit: allow nillable and min/max occurs for each element
RESOLVED: Allow nillable and min/max occurs for each element
Discussion about unique wire signatures, operation name, etc. -- deferred until discussion of proposal snajiva posted
[12] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0161.html
--------------------------------------------------------
10:30 Break
10:50 Binding enhancements. New draft [13, 14]
- Unresolved proposal: Drop <soap:binding>: drop @protocol, change
<soap:address>: add @protocol.
[13] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml#Binding
[14] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml#Endpoint
Sanjiva: Get rid of soap:binding element and add info to soap:address.
[JacekK: glen, SOAP 1.2 says Protocol Binding, so attribute protocol is good (because protocolBinding would be confusing with WSDL bindings, IMO)]
glen doesnt want to call the attribute protocol -
[GlenD: protocolBinding]
Compromise position - call @ protocolBinding
Sanjiva: Observes there is no transport specific info in the binding, so
move it to the endpt.
Discussion follows -
Motivation: make the binding more "reusable"
Tom: Doesn't see compelling use case for reuse.
Glen: I have a soap binding - uses reliability, tx, etc. I would like
to reuse that info, w/o haviung to rewrite it for each specific
endpt/protocol.
Sanjiva: So if i'm using soap/http and soap/jms, I'd have to copy the
info -- AND maintain it.
Jacek: Argues this proposal adds to what I have to know about the
endpt.
Sanjiva: The binding and endpt info really are coupled.
Jacek: Minuses -- currently need binding qname and endpt url, with
Sanjiva need to add soap protocol uri.
Straw poll -- 5-5- 7 or so abstentions
[JacekK: is the reusable-bindings stuff still in the queue?]
Marsh -- appears that proposal does not have widespread support -- so we will continue with the status quo
--------------------------------------------------------
- Issue #84: Are SOAP header faults needed? [15]
[15] http://tinyurl.com/mwuy#x84
TOPIC: are soap header faults needed
Glen: Describes in soap that when there is a fault associated with a
header, then the "detail" fault info goes in the header.
Specified in bp 1.0.
Consider req-resp case -- if there's a problem in the body -- get back a soap fault, hopefully with relevant info in the detail.
If there's a problem with a header -- get back a header, a "header fault", with the relevenat info about what was wrong with the header, in the returned header.
Defer issue.
--------------------------------------------------------
12:00 Lunch
--------------------------------------------------------
Scribe: Tom Jordahl
13:00 [agenda change: Binding Enhancements (cont.) replaced with:]
Media type handling in WSDL 1.2 (Philippe) [43, 44, 45]
- Update on MTOM (Jean-Jacques? Glen?)
[43] http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0028.html
[44] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0088.html
[45] http://www.w3.org/2003/09/0912-media-types.html
Jacek summarizes SOAP MTOM project and current status
[dbooth: MTOM = http://www.w3.org/TR/2003/WD-soap12-mtom-20030721/]
[dbooth: (Message Transmission Optimization Mechanism)]
[jeffsch: FYI here's the predecessor to MTOM: http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html]
[dbooth: Philippe's presentation on Media types: http://www.w3.org/2003/09/0912-media-types.html]
Phillipe: Describes media type problem - type info is in binding, hard
to generate interface bassed on Schema/portType only. If we
move the type information to interface, we can only type a
single element, which is too limiting. So we need to move the
type info in to the Schema. Oulines possible solutions:
1. PASWA WSDL definitions - WSDL defines new xmime:Binary
type that can be used in Schema. Also defines WSDL schema
extension, xmime:Accept. SOAP extension: Element has a
xmime:MediaType attribute.
2. Schema type extension. No SOAP extensions, just use xsi:type.
Just use the namespace http://iana.org/mime, and the types it
defines.
3. Schema Annotation. Keep mime content and move it to the
annotation element of the XML Schema. Also requires SOAP
extension for mediaType attribute.
4. Schema notations. Create one notation for each media type,
then use feature of XML Schema to reference them as notations.
5. Use the TAG mapping between URI to media types.
Discussion on the merits of the various solutions....
Jonathan: Thinks there should be a simple way to map the binary defined
in the schema to a single mime type. Outlines an extension
attribute to simpleType that would simply indicate the mime
type of the binary data.
Discussion continues on how to make Jonathan's simple proposal work.
[dbooth: It's important that an off-the-shelf XML Schema processor be
usable in the case when the application doesn't care that the
base64binary is specifically jpeg.]
Jonathan's Proposal: Create a NOTE to hand off to XML Schema and/or XML
Protocol Working Groups defining the namespace and attributes
for mime type.
Looking for a volunteer to write up a note describing new Schema attribute approach.
Jaff S. points out the the issue needs a champion, or it may not get done.
[Marsh: ACTION: potential editors to apply to Chair :-)]
--------------------------------------------------------
14:00 Patterns. New draft [16]
- Choose specific patterns for the standard [17]:
1. TF recommendation: drop the old request-response (defined
in terms of "same channel") and drop one of the multicast-
solicit-response patterns, as subsumed by others [18].
2. Sanjiva's proposal: drop any pattern not used in a
normative binding in our spec.
3. Tom's proposal: drop the "multi" patterns.
4. Amy's proposal: at least the patterns in WSDL 1.1.
[16] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.xml
[17] http://lists.w3.org/Archives/Public/www-ws-desc/2003Aug/0010.html
[18] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/recommendations_clean.htm
Proposals:
1. drop the old request-response pattern. The IN/OUT pattern now clearly
specifies that the OUT goes back to the node that sent the IN. We are
left with 6 patterns now in the current draft: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.xml. [Marsh: seems to be
consensus that we already accepted TF recommendations.]
2. Sanjiva: Drop anything without a binding in our spec.
3. Tom: Drop the multi-cast
4. Amy: Keep at least what we had in WSDL 1.1.
The above are proposals from various people. Several arguments for keeping patterns even though we don't have bindings for them.
Jonathan: keep patterns in spec for CR, examine any work that attempts
to create bindings for patterns that we didn't?
Sanjiva: Let's take a shot at creating bindings for the patterns (like
OUT/IN) we don't have bindings for.
Much discussion about history of the patterns and how users may use patterns we don't spec bindings for.
15:00 Break
--------------------------------------------------------
15:20 Patterns (cont.)
Three options:
1. have patterns in spec
2. have patterns in a note
3. let the industry do the work, we don't specify them
[jeffsch: Kevin, do you mean this? http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0054.html]
[KevinLiu: yes. thanks for dig this out, Jeff.]
JeffSch: Don't take these patterns out and prevent him and others from
taking advantage of them. Makes a strong statement to keep the
current 6.
[Roberto: keep those for which there is a normative binding (currently 2)
and publish the other ones as a note]
[jeffsch: SOAP Email Binding http://www.w3.org/TR/2002/NOTE-soap12-email-20020626]
[jeffsch: (May be only request-response)]
[jeffsch: Sanjiva proposed retaining all 6 patterns in the normative part
of the spec but clearly identify which bindings support which
patterns.
[jeffsch: As a compromise.]
Roberto: The 4 are good, but the multi patterns seem very fuzzy.
[prasad: I would like to observe that in most cases the same bindings that
are applicable to an interface of In-Out (In first) type of
pattern are also equally applicable to the interfaces that are
based on the patterns like Out-In (out firrst). Only issue is
how to obtain the end point address for Out first patterns. This
can be achieved via many out-of band (to the operation) means.
Including using another operation in the same port to register
the end-point (wh...]
[jeffsch: From http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0044.html...
The example only illustrates output-only, but it would not be
difficult to construct a similar example that illustrated
output-input.
Jonathan: Keep 4: IN and OUT.
Jonathan: Tell Amy we want to remove the multi patterns. See what happens.
Grumbling about removing multi patterns, particularly without some sort of binding. Chair attempts to pin down the working group to decide if we are going to remove the mutli's and/or the OUT's.
[dbooth: Sanjiva's proposal: (1) We retain all 6 pattern, and (2) We document which ones are supported in the bindings.]
Straw poll on Sanjiva's proposal:
For:12 Against: 3
Sanjiva: Variant, cut the 6 down to 4 (remove multi's)
For:12 against: 4 (different people)
Vocal group would like to see viable binding proof of concept in order to decide if we remove the multi patterns.
Dbooth: Conditionally approve Sanjiva's proposal to adopt the 6, subject
to seeing a proof of concept at the next F2F
[Roberto: and mark the multis as "at risk".]
Jonathan: Concensus on keeping 4, with 2 in danger of being removed unless
we see proof of concept binding.
--------------------------------------------------------
16:00 Binding message references in the component model [19, 20]
[19] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0077.html
[20] http://tinyurl.com/mwuy#x89
[inadvertently skipped?]
--------------------------------------------------------
16:30 WSDL Validator demo (Arthur)
Arthur shows the cool validator and makes a plea for others to join the project.
[Roberto: http://www.eclipse.org/wsvt/]
Interested parties can get info at that URL.
[plh-lap: linked from http://www.w3.org/2002/ws/desc/#tools]
17:30 Adjourn
Received on Monday, 29 September 2003 20:08:56 UTC