- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 6 Aug 2003 10:12:48 -0700
- To: <www-ws-desc@w3.org>
--------------------------------------------------------
Wednesday 30 July
--------------------------------------------------------
09:00 Introductions and logistics
--------------------------------------------------------
Present:
David Booth W3C
Roberto Chinnici Sun Microsystems
Glen Daniels Macromedia
Youenn Fablet Canon
Steve Graham Global Grid Forum
Tom Jordahl Macromedia
Philippe Le Hégaret W3C
Amelia Lewis TIBCO
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle (TH-F)
Dale Moberg Cyclone Commerce
Arthur Ryman IBM
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates (TH-F)
Jerry Thrasher Lexmark
Steve Tuecke Global Grid Forum
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Observers:
Martin Chapmann Oracle (W)
Phone:
Steve Lind AT&T
Kevin Canyang Liu SAP
Allen Brookes Rogue Wave Software
Regrets:
Jean-Jacques Moreau Canon
Bijan Parsia University of Maryland MIND Lab
Adi Sakala IONA Technologies
Bryan Thompson Hicks & Associates (DARPA)
(may be others, registration system hiccups prevent a complete list...)
--------------------------------------------------------
- Assignment of scribes
Draft Scribe List:
Wednesday AM Jerry
PM Glen
Thursday AM Amy (swapped with Jeffsch)
PM Sanjiva (swapped with DBooth)
Friday AM Arthur
PM JeffSch (swapped with Amy)
--------------------------------------------------------
Agenda Review:
--------------------------------------------------------
09:10 Publication plan
--------------------------------------------------------
Survey of remaining work
Part 1: Open proposals:
Major work items for Part 1:
1. Removing message
2. Binding enhancements
3. Attributes
4. Endpoint references
Other Part 1 ToDo items:
1. Properties & features guidelines
2. Describing binary data
3. ServiceGroup ?
4. Open issues:
misc (~7)
editorial (2)
Part 2:
Open proposals:
1. Patterns TF recommendations:
Open issues:
none known
Part 3:
Open issues:
SOAP 1.2 support (~7)
HTTP binding (~3)
misc (~11)
editorial (~11)
Primer: Outline only
Expected Last Call dates?
JMarsh discussed the possibility of last call in the November time frame.
This is dependent on the results of the this F2F (closing remaining
issues in part 1 is requirement). Last call may end up slipping a couple
of months.
--------------------------------------------------------
09:30 Patterns Task Force (report/recommendations)
--------------------------------------------------------
DBooth presented the recommendations of the WSD Patterns TF.
Document located at:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/recommendations_clean.htm
--------------------------------------------------------
Background:
--------------------------------------------------------
4 MEPS in WSDL 1.1
Earlier F2F we decided to look at 8 MEPS.
TF assigned to recommend what MEPS are required/desired
for WSDL 1.2 and to look at what "properties" of each MEP
distinguish from another.
--------------------------------------------------------
Presentation:
--------------------------------------------------------
DBooth presented and the group discussed the 12 variations of the
Input/Output pattern and the motivation of each variation (see
presentation slides).
Current definition of In/Out does not specify the target of the
Output messageor any generated fault. Hence the variation explosion.
Question? How does Party A(client) in the diagrams know whether to
expect/wait for a reply/fault from Party S(service) in the In/Out MEP.
How is this described in the WSDL document?
Outline of the recommendation:
1. Patterns describe MINIMAL behavior.
(See definition of this concept in the presentation slides)
2. Patterns describe parties as variables
Any pattern containing more than one message must specify the
sender and recipient of each message.
JeffS pointed out that this implies that some bindings may limit the
ability to use some MEP's with this specification requirement.....
(agreed)
3. The recommendation for specific MEPs(6 to adopt, 2 to drop)
TF recommends adopting the following:
a. Pattern p1a-nf (In-Only pattern)
()
b. Pattern p2e-nf (classic In-Out pattern)
(separate fault rules determine what the output or faults
messages can be)
(the fault rules that are "matched to the MEP" describe whether the
fault terminates the message exchange or not (i.e. can the In-Out
generate both a fault and output)
After discussing in depth the way the faults are treated/applied
in this pattern, it was decided (Dbooth) to continue with the
pattern discussion/adoption and look at how/what fault rules apply
later.
c. Pattern p4c-nf (In-Multi-Out pattern)
One message (all of the same type) sent zero or more times.
JeffS asked if there is an implied order to the multi-out messages.
DBooth asserted that the "pattern" should specify if order should be
preserved. Others asserted that this is a result of the pattern and
it's associated binding.
Was an assertion that MEPs should specify this to allow client code
to be written without regard to binding details.
No decision on whether order is implied or not or how that might
occur.....revisit if this MEP remains in the specification....
--------------------------------------------------------
10:45 am Because of time limits it was decided to press on with the
presentation.....
--------------------------------------------------------
Other MEPS recommended by the TF include:
d. Pattern p5a-nf (Out-Only)
e. Pattern p6b-nf (Out-In)
f. Pattern p7b-nf (Out-Multi-In)
TF recommends dropping the following previously defined MEPs:
a. The "Request-Response" pattern
(superceded by p2e-nf)
b. The "Multicast-Solicit-Response" pattern
(subsumed by p6b-nf)
--------------------------------------------------------
11:00 - ~11:20 Break
--------------------------------------------------------
Dbooth presented the patterns that were NOT recommended by the TF and
then outlined the reasoning behind that. (see presentation slides)
Remaining issues form the TF recommendation:
1. Fault Rules. Could they be simplified to a single message triggers
fault rules? Current fault rules need to be re-examined.
2. Correspondence/correlation with SOAP MEPs
--------------------------------------------------------
Discussion on the presentation:
--------------------------------------------------------
JeffS asked for a clarification on the definition of minimal in the
first TF assumption.
The concept allows that additional messages and behavior may occur
between client and the service, or between either the client and
service and other parties, whose details are outside the MEP
description.
There was some discussion about the idea that a MEP may not fully
describe ALL interactions between parties.
--------------------------------------------------------
Sanjiva wants time to further investigate/discuss the TF's recommended
MEPs before deciding to adopt the recommendation. Particularly with
respect to the binding definition of each of the MEPS in the
specification. Sanjiva asserts that ANY MEP that's included as
normative in WSDL 1.2 must contain a normative binding definition
as well.
There was some consensus, however there was concern that output only
and output first type MEPs may require extension to the SOAP over HTTP
binding to be defined.
--------------------------------------------------------
There were some that wanted to not include any of the "multi" MEPs (i.e.
p4c-nf and p7b-nf)
--------------------------------------------------------
It was decided to defer any further change to the TF's recommended MEPs
until they are reviewed further by the group.
--------------------------------------------------------
TF Recommendations summary (with group opinion):
--------------------------------------------------------
1. Pattern does not exhaustively define all messages between the named
parties (general consensus)
2. Patterns define only details relevant to more than one party.
(general consensus)
3. As a result of this (2), the participants involved in the pattern
must be listed. (general consensus) (open issue on it's syntax, what
attribute etc. and the fault if it's not there)
4. Using recommendations 1 and 2, refine the list of MEPS down to 6
(see presentation or above for list). (not yet general consensus that
these are the appropriate MEPS, need more review by the group)
5. Given the MEPs chosen, need to now revisit fault generation rules.
(consensus that this must be done, but there is currently no proposal
to review)
--------------------------------------------------------
*** Action: Amy to generate proposal for (5).
--------------------------------------------------------
Additional guiding principle that wasn't include by the TF
recommendation.
6. ANY MEP that's included as normative in WSDL 1.2 must contain a
normative binding definition as well. (not yet complete consensus)
--------------------------------------------------------
*** Action: Editors to incorporate the first three recommendations
into the draft.
--------------------------------------------------------
The Patterns TF is congratulated for it's efforts and is temporarily
suspended.
--------------------------------------------------------
12:30pm Recess for Lunch.
--------------------------------------------------------
13:30 Removing message.
Investigating idea to cleanly separate interop at the message
format level from interop at the programming model level. Proposal
from Sanjiva [4]. Programming hints [5, 6]
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0025.html
[5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0114.html
[6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0120.html
Scribe: Glen
Sanjiva's Presentation re: removing (or not) <message>
(see archive for PPT)
Sanjiva: Complexity (multiple ways of doing things) encourages profiles.
Might be nice if we did a good enough job to avoid requiring
profiling. Would be great to essentially go with old proposal -
duplicate functionality of <complexType> for exactly what we
need.
Umit: Yes!
Sanjiva: Can't prescribe usage; you can always drop to schema/single-
part systems. Both patterns are already in use today.
Arthur: Can't neatly describe some things (unions, com areas, overlays),
need full schema. Since these things aren't simple you can't
break them into simple parts.
Umit: Don't push off the work about defining this stuff to the wsdl
authors.
Sanjiva: If we retained part, part could ONLY be simpletypes, and you
use multiple parts to get structure... people would just go
back to 1.1.
In order to support this proposal, you need to add a lot of syntax to
WSDL on to current proposal. Drop <message>, point <input>/<output>/
<fault> at single <xsd:element>s.
Umit: Are the body/header QNames disjoint?
Sanjiva: Not necessarily
Amy: How does header apply outside of SOAP?
Philippe: Current HTTP binding is based on part names - that's how
replacement works. How does that work?
Sanjiva: Good Q. Same question for java binding, etc.... Couldn't send
XML over HTTP easily using old bindings.
Philippe: You can with SOAP 1.2.
Tom: If you specify a fault details QName, you need to put multiple
pieces of info inside a wrapper?
Sanjiva: What does WS-I state?
Jeffsch: Other stuff (fault code etc) we need to specify about faults,
let's hold off on this for a bit.
Sanjiva: OK not to support more than one element inside <soap:Body> -
WS-I already profiled it away, Noah M doesn't so much like it,
etc...
Tom: There are examples of this in use...
(SOAP encoding discussion)
Tom: Lots of people working with RPC who want to move to WSDL 1.2.
(consensus to hold off on encoding issue)
(RPC discussion... signature round-tripping, metadata)
Jeff: Microsoft's position is that we shouldn't be exposing
programming models in a normative way... it's about wire msgs.
Martin: It's not just about roundtripping, it's also about dispatching/
upcalls.
Sanjiva: Wire is fixed, so the discussion is about bindings.
Jeffsch: Wire format was, essentially, always fixed, but the fact that
there were potentially multiple ways of expressing that in WSDL
was a problem.
Martin: If Signatures -> WSDL is many -> one and WSDL -> Sig is one ->
many, we're fine.
Umit: No, we shouldn't let people generate different signatures from
the same WSDL.
Jeffsch: Our companies may agree on wire formats but we won't agree on
programming models - can't force that.
Martin: By eliminating the operation name on the wire, it means "the
name of an instance of an MEP". So now if I have a schema element
representing data (employee record), I need wrapper elements
around them to disambiguate operations....
Sanjiva: The old style="rpc" had the same semantics, just built in to
the language.
Jeffsch: Several names in WSDL that are never evinced on the wire....
we could make that clearer.
Martin: People do infer semantics from operation names...
Sanjiva: Could rename <operation> to <interaction> - element syntax to
group a set of messages which go back and forth.
Roberto: WS-I says you need to disambiguate with something that exists
in the body itself.
Sanjiva: SOAPAction can help with this - <interfaceURI>#<operationName>
Roberto: Operations are more than just groupings if they have element-
based dispatch (RCP, BP).
Glen: Why not just say for ALL operations (literal or RPC) you will
always see the QName of the operation as the SOAP body child?
Amy: It's getting SOAPisher and SOAPisher!
Glen: Dispatch should be on operation information (QName) - doesn't
matter how it gets there.
Roberto: The unique requirement today doesn't force you to wrap, it's
just a suggestion.
Sanjiva: If you don't have a schema for it, it's hard to validate.
Jeffsch: This is a synthetic element, and there's some overhead there.
Let's discuss this - it's a choice between automatically adding
mechanism at some expense for the middleware, and using a
workaround which is known but at some expense for the users.
(moving on to Sanjiva's RPC signature proposal)
Sanjiva: Use encodingStyle to indicate following a certain set of
conventions in the schema. No default for this attribute.
Rules are basically SOAP RPC rules, wrapper element with local
elements inside, response is "<operation>Response", etc...
Jonathan: Can use custom values for this as well? What about a list?
Sanjiva: No lists, was in the original proposal but removed.
Jonathan: What about other metadata people might want to define?
Umit & Roberto: parameterOrder is important - you can have an output
param that appears 1st in the signature, for instance...
Jeffsch: Is it possible to define a single set of rules, tagged with a
URI, that encapsulates everything necessary?
Umit: Maybe, but as my mail said this isn't sufficient yet.
Sanjiva: This isn't final yet.
Umit: These rules are OK for RPC over doc/lit - you put the burden on
the user to describe the messages. Everything has to be added
and rules have to be followed by the user. WSDL 1.1 lets us do
this "automatically", and this suggestion forces the user to do
it.
Glen: Have we gotten rid of style yet?:)
Umit: I'm afraid writing WSDL by hand will be error-prone and more
difficult. Users will need to convert old WSDLs (write wrapper
elements, etc).
(Sanjiva types furiously)
(Sanjiva demonstrates a 1.1 vs 1.2(w/o message) example which looks pretty darn similar)
Tom: This is wrapped doc/lit.
Roberto: Messages are already so abstract that people name them fooRequest/
fooResponse anyway (based on the operation).
Sanjiva: The problem is that for a given SOAP message, there were/are
two different ways to describe it. This proposal attempts to
have one way to do it which is happy for both the RPC (same
signature on both sides) and the doc/lit folks.
Martin: RPC should be a subset of the pure messaging usage.
Umit: But putting the wrapping burden on the user is bad.
Jeffsch: Is Oracle more concerned about WSDL generated from code, or
WSDL written from scratch?
Martin & Umit: both
Jeffsch: Since an operation is potentially a group of related messages
(not just req/resp), applying method call semantics to it is
not necessarily correct.
Martin: Hey, if we get rid of operation it could be "GET", "POST",
etc...:) (laughter)
Jonathan: How about a break?
Sanjiva: Can we move forward in this direction?
Tom: Does this get rid of style? If not, you can wrap twice (once
by user, once by style="RPC")
Amy: What's happening is that we're moving binding out of binding
and into interface.
--------------------------------------------------------
15:00pm Break
--------------------------------------------------------
Martin: Two design centers - start from code, or start from WSDL....
Sanjiva: If not starting with signatures, there's no huge value to
defining schemas to particular rules. If manually writing
WSDL, user has to learn and follow the rules if they have a
signature in mind that they wish to encode in the schema
Amy: Message is dead simple form of schema, and part of the reason
for keeping it is that it's easy to understand. Personally,
would like to see WSDL get out of the business of writing a
schema language... current stuff is hard to validate,
confusing, etc.... would like result (WSDL 1.2) to be easier
to plug into a validator. Maybe instead of removing message
we define it such that it's a simple transform away from
actual schema....
Roberto: Message stuff doesn't interact well with existing schema
tools - syntactic sugar (new stuff) doesn't help with this
Arthur: I think we're going to end up starting from schemas, and
generating proxies from those, not starting from classes and
generating from there.
Umit: what is the real harm in a syntactic sugar and translation
approach? If rules are simple for machine to follow, should
be able to write it....
Sanjiva:
<operation name=ncname>
<input [element=qname]>
<part name=ncname type=qname/>*
</input>
</operation>
Umit: No minOccurs/maxOccurs....
Sanjiva: Slippery slope - forget it.
Umit: But this was the original problem....
Jeffsch: Lack of expressiveness of message/part - but didn't want to
reinvent schema.
Sanjiva: This is a simplification - especially wait until you see the
binding stuff... that gets much easier.
Arthur: Makes things simpler/clearer
Umit: we're talking about WSDL', expanded from syntactic sugar.
Sanjiva: This is a pain for tools vendors, who need to understand the
"subset" of schema that part etc. defines.
Amy: (tossing her "cat among the canaries") Forget about SOAP,
consider the next Big Thing... are we writing something that
can handle arbitrary other forms of exchanges?
Sanjiva: This isn't much of a restriction.
Umit: This is pretty SOAP specific.
Sanjiva: No, you can bind (for instance) to Java directly....
Tom: So where are we?
(discussion of syntactic sugar pros/cons)
Amy: Don't like syntactic sugar because it gets us back into
defining a schema language.... maybe we need something
different for RPC, but defining wire messages should be
delegated to schema/relaxNG/etc.
Umit: I agree - but it should be simple to translate the "sugary"
version to the "real" version.
Sanjiva: Tools vendors need to support the sugar.
Jeffsch: But this is really about a human writing the WSDL.
Umit: I'm not talking about full schema... just min/maxOccurs,
nillable, and that's about it.
Sanjiva: Can we vote about accepting this and perhaps adding syntactic
sugar for making it easier for WSDL 1.1 users to write this
stuff?
SteveG: Syntactic sugar isn't a good idea - too complex. Whole
proposal in general is good.
Philippe: Complexity we're removing by getting rid of part, we add again
by putting it into the schema. Syntactic sugar is good. Don't
want <choice>, etc....
Youenn: Can use XPath with just schema, so syntactic sugar would make
that a little harder...
Sanjiva: If they need to know the mapping from sugar -> elements anyway
(to refer to them in bindings, etc), and both exist in the same
document (sugar in <input>, reference to the "real" element in
binding), that's difficult and confusing.
Jeffsch: If you want to reach into a particular operation and talk about
it in a binding, you need to refer to it in the same way you do
at the definition time, OR you need to know the translation
rules. HTTP binding for instance, putting sub-elements into
query-string params....
Umit: OK, it might be not quite ready for prime time.
Tom: If we're going to get rid of message (which I'm not 100% on),
then I don't think we should put stuff in the operation.
David: Given that the syntax is yukky, a lot of people will be copying
and pasting... is there still a need for syntactic sugar then?
Jonathan: What about cut from 1.1 paste to 1.2?
David: That's a different situation.
Sanjiva: Doesn't help unless you put it all the way down to bindings as
well.
Umit: syntactic sugar is a boon to WSDL-1.1 focused people, of whom
there are many.
Sanjiva: We should talk about getting rid of message first?
Dale: Not quite baked yet - headers not defined for non-SOAP bindings,
etc. Other type systems seem to have dropped away...? Edge
cases seem a little unclear.
Jonathan: Do we anticipate problems with bindings?
Dale: Hopefully straightforward.
Roberto: Do we need the header attribute at all?
Sanjiva: In 1.1, headers were parts, so wanted to convey same
expressiveness.
Roberto: So leave it to the binding. This piece goes here, this one goes
there.
Glen: I don't think headers belong in there at all.
(brief discussion about headers / modules, tabled until later)
Youenn: Can element be relaxNG, etc.?
Sanjiva: What I had in mind was a QName pointing to schema.... but maybe...
Dale: encodingStyle rules would need to be different for relaxNG,
so you'd need a different URI.
Jeffsch: I think we could define a set of rules over a known set of
schema languages under a single URI. But we might need a new
URI for new unforseen schema languages....
Alan: Very wary of the whole idea of syntactic sugar, especially if
there are additions above and beyond WSDL 1.1 syntax. Generally
in favor of the rest of the proposal.
Kevin: Generally in favor, but some concerns about backwards
compatibility.... rename to WSDL 2.0?
Umit: How normative is this?
Jeffsch: If you care about interfaces, you confirm that they followed
the rule. If you don't, you just ignore it.
Umit: You should fatally fault if the rules are specified but not
followed regardless of whether or not you use the information.
Jonathan: OK, so a document which screwed this up could be considered
non-conformant, but still be usefully utilized in some contexts.
This is a separate issue, let's deal with it separately.
Consensus is that it's OK to ignore invalid stuff contained inside ignored
(or not understood) extensions. But it's not OK to have invalid stuff in
the parts of WSDL you do understand.
Umit: You need to make this encodingStyle thing required, and all
processors must verify it.
ISSUE: What does a WSDL processor do when it encounters invalid constructs
which it does not care about?
Jonathan: Let's vote. Two ways to proceed. 1) refine the proposal further
(syntactic sugar etc) first, and then vote, or 2) vote on the
proposal first and open issues against it. Would people vote
differently depending on which way we went?
Proposed order of voting/decisions:
1) Remove message per Sanjiva's proposal (@body, @header)
2) Add hints re: method signatures
3) Proposed rules for schema writing
4) Add syntactic sugar for operation -> schema
Umit: What about the other proposal? Essentially Sanjiva's old
proposal - introduce parts in <input>/<output> with minOccurs/
maxOccurs, but without the "implied schema" step. Rename
operation -> messageExchange?
Tom: What about SOAP encoding?
Sanjiva: This is a binding discussion - wait 'til later, but maybe we
can reintroduce use or something....
Tom: Don't want this to get overlooked.
Arthur: Part was good for mime types. Have we decided how to deal with
that with schema?
Sanjiva: We can do the PASWA thing.
Jonathan asks for objections to 1+2+3 above.
Oracle objects.
VOTE: 1 + 2 + 3 above
W3C: Yes
Sun: Yes
Macromedia: Yes
Canon: Abstain
Grid: Yes
Tibco: Yes
Cyclone: Yes
IBM: Yes
Microsoft: Yes
Lexmark: Yes
HP: Yes
Oracle: No
Rogue Wave: Yes
SAP: Abstain
11 yes
1 no
2 abstentions
Straw poll on #4: Should we adopt some form of syntactic sugar to better support the RPC use case in the operation construct?
In favor: 2
Not: 9
Umit Objects to recording consensus to not investigate
--------------------------------------------------------
17:30pm Ajourn
--------------------------------------------------------
Received on Wednesday, 6 August 2003 13:13:56 UTC