- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 16 Nov 2004 12:49:54 -0800
- To: <www-ws-desc@w3.org>
Web Service Description Working Group
Minutes, FTF meeting 11 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
Arthur Ryman IBM
Jerry Thrasher Lexmark
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
-------------------------------------------------------
Thursday 11 November
-------------------------------------------------------
Scribe: Roberto
Chair: Hugo
09:00 Test suite issues
- Z update?
Arthur describing the spec draft that has Z in it...
updated spec is
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html
build.xml has been checked into cvs
ACTION: Hugo to update the makefile to generate the spec with Z
Arthur showing some examples from the spec
Arthur explaining how the collapse/expansion of the Z sections in
the spec works
Arthur: we should look at collapsing the infoset mapping sections
just like the Z sections
Hugo: Printed versions should not contain these "hide/show..." links
DBooth: Have only one link at the top for hiding all sections
Asir: What is an element content model?
Arthur: It corresponds to element declaration components (which are
not
very well defined by the spec)
[asir: related LC issue is LC63,
http://www.w3.org/2002/ws/desc/4/lc-issues/#LC63]
Asir: There is an issue around uniqueness of type system components
given their qualified name (LC63)
Arthur: Found some problems in the spec while doing the Z translation.
Will send email. We may need extension components.
Roberto: They'd look like annotation components in schema perhaps?
Arthur: There are references to extension components in the operation
name section and the designators section. We lost the notion
of nesting and parenting in the component model. Components
should have the same parenting constraints that are implied
by the designators syntax.
Roberto: For the sake of discussion, could we use Z directly on the
infoset view of a description and skip the component model
altogether?
Arthur: The component model may help with include/import. Z could
be seen as adding constraints beyond what XML schema says
Umit: Got comments that the second level of abstraction (components)
is foreign
DBooth: We got a comment to the same effect by Martin Duerst
[pauld: +1 to losing the component model (if at all possible)]
[kliu: +1 to paul]
Arthur: The spec would be shorter; the section on mapping the infoset
to the component model could be written as Z
Roberto: The component model was meant to make the spec writable by
humans by making it easier to deal with all the constraints
[DBooth: +1 to kliu]
Hugo: Won't Z introduce more problems than the component model does?
Roberto: The short version will gloss over some details
Umit: Then people are forced to learn Z to figure out the details
Arthur: The english would be complete enough for users, but not for
implementors
DBooth: It's reasonable for an implementor who has a precise question
on the meaning to look at the Z notation
Arthur: We'd be refining the infoset component model, instead of
having
two separate models (infoset-based and component-based). It
amounts to specialize the infoset component model
[pauld: I think the current spec's dependence upon the component model
means it is targeted too much at developers of tools, rather
than authors of WSDL documents]
Glen: Interesting direction, but it's a major change
[dorchard: +1 to losing component model if possible or at least
minimizing the text a WSDL author has to read on how to go
from infoset ot component model.]
ACTION: Arthur to write up a sample of what a rewritten spec using an
infoset-based component model would look like
DBooth: It would be a major improvement to really simplify the spec
-------------------------------------------------------
10:15 Test suite
Arthur: There is a test-suite directory in CVS
Arthur describing
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/TestSuiteCon
tents.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1
Arthur: Look at the spec and schema, compile a list of every name that
appears in it (attribute, enumerated value, uri, ...), every
name in the vocabulary must appear in at least one test case.
Additionally, list all test assertions (constraints, etc) and
make sure we have at least one "bad" test case that violates
that assertion. Also have a TCP monitor and make sure the
messages follow the rules. Test suite would contain a list of
WSDLs with corresponding messages.
Roberto: How does that help passing the "two interoperable
implementations
per feature" barrier?
Anish: In xmlp we didn't come up with valid soap messages. Rather we
invented some semantics for a service, like "echo", described
the semantics, then described what's supposed to happen.
Arthur: I give you (an implementor) a WSDL and an input message; you
implement the service; then send the message to the service.
Same thing for the client.
Roberto: But it doesn't test interoperability!
Anish: WS-I defined a sample app, non just a validator
Umit: Part 1 is seeing whether a WSDL document is a valid document,
but that doesn't help interoperability. Is it the only
requirement or more (the test suite)?
Hugo: Both; the test suite is the tool we use to show
interoperability.
Arthur: Sent note in April, asking for ways to improve the quality of
the spec. Showing messages that conform to a description
helps
with that.
Roberto: For interop, we need something similar to what xmlp did
Arthur: That was step 2; step 3 is message exchange patterns. Created
directories in cvs to check stuff in
(documents/exchanges/messages)
[pauld: you can use the test messages directly, as canned input, or
pass them into an implementation, or use them to build a
hard-wired implementation at a reference end-point xmlp style]
[pauld: agreed, for cr we need two or more implementations to
interoperate,
but the test messages should give something to test individual
implementations against - in the very least it bootstraps the
interop testing]
Anish: We cannot get away without defining any semantics at all.
Testing
f&p requires semantics. If you want people like the
soapbuilders
to help, we need semantics.
Arthur: Call for contributions of test cases
[pauld: Suggests that it will be interesting to see which aspects of
the
spec don't get test cases. could be a useful indication of
what
we can expect to be actually implemented. Test suite could
become a defacto "profile"]
ACTION: Arthur to issue a call for test documents
ACTION: Anish to propose additions to the test suite for the purpose
of
interoperability testing.
10:55 Break ----------------------------------------
11:15 MEP issues
- Issue LC50: Message Exchange Patterns -- p2c and/or p2e [29]
[29] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC50
[DBooth:
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Sep/0048
.html]
DBooth explaining the issue
Sanjiva: Nodes are logical nodes
DBooth explaining the proposal and its rationale (from
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Sep/0048
.html)
DBooth: What's the difference between nodes and replyTo?
Sanjiva: With replyTo, it's still between two (logical) nodes
Anish: "node" is not defined, MEPs that talk about node N don't mean
much until we define it. Bindings may constrain the
destination
for a reply (e.g. SOAP/HTTP in 1.1 does)
Umit: When writing MessageDelivery we noticed the multiple
interpretations
of "node"
Sanjiva: Not correct to say that you're violating the binding; we had
a
discussion when DaveO proposed an asynchronous binding. We
asked
the XMLP group and couldn't come to consensus on their side
on
whether the soap response in the HTTP binding has to be in
the
HTTP response.
Glen: If a response comes back with a header targeted to the node
that
sent the message, that header must be processed
Sanjiva: It's still a logical notion
Anish: With the HTTP binding you can't do that
Sanjiva: The XMLP group didn't agree. We are talking about WSDL
patterns;
in our spec, nothing says that the response has to go to the
same address/machine/anything
DBooth: If the response goes back to the same logical node, I'm ok
with
that. With WS-A I can address the response to a different
location;
does that other location represent the same logical node?
[Anish: Sanjiva -- here is my response to your query on XMLP --
http://lists.w3.org/Archives/Public/xml-dist-app/2004Jul/0013.html]
Glen: Yes, if you're using in-out
DBooth: Need to exemplify sending a reply back to a different node.
Proposal is to define a new MEP
Hugo: How are you going to differentiate between being the same
node or a different one?
Roberto: Applying the 80-20 rule, we shouldn't add a new mep
Anish: Example of specifying a separate node as the destination for
the response
Sanjiva: Are you doing a request-response?
Anish: Yes
Umit: Remove the request-response and define it as p2c. The
description
is from the point of view of the service
DBooth: p2e is a specialization of p2c. Gudge argued for p2c. Makes
an
argument that both patterns are needed and that tools should
recognize the relationship between them
Roberto: Do not remove p2e. Cannot just define a super-general
pattern
that covers everything else -- it doesn't help either tools
or
users.
Sanjiva: p2e is needed, because p2c cannot be bound to SOAP/HTTP as it
stands.
Anish: You can bind p2c to soap but you have to define new soap meps
to
be able to use it
Sanjiva: We have consensus that you can use replyTo, faultTo with the
current meps
Anish: Given that we haven't defined node, saying that there are
A,B,C
or just A,B is the same
Umit: Only one pattern for request-response
Roberto: meps were from the the service's point of view, but if you
allow clients to set replyto, faultto then it is from the
point
of view of the client. Tools will generate patterns and
generate
things correctly and humans will not have to specify the
endpoints and what not]
[Sanjiva: +1 to Roberto]
Roberto: Client can do what they can and things are logical. If you
want to argue that u want to add this pattern then we have to
define a binding for it. Otherwise we should not put it in.
Hugo: We agree that node is underdefined
Roberto: Flexibility in the p2c binding translates to additional
complexity for developers
Sanjiva: To use p2c you need to define a new soap mep, not just a new
binding
Anish: Do we need to say something more about what a node is?
Hugo: We agreed to that
DBooth: Tools could still map p2c to a simple RPC-like form by
default,
or via a switch that the developer specifies
Sanjiva: How do you identify A/B/C in p2c?
DBooth: See spec, part 2, section 2.2.3. Message references are arcs
in the diagram
Sanjiva: Soap meps talk about nodes identified by a URI and that does
not imply that it has just one address. We should generalize
that definition
DBooth: WG has become more permissive on what meps to define. Also,
addressing extensions have received more attention. A toolkit
can have an option to treat the generalized pattern as the
more specific one
Roberto: The last point, only on the client side
[pauld: not sure if this helps, but notes you need two things to pair
the messages in a request-response MEP - a return path and a
correlation. a synchronous transport like HTTP provides both
implicitly..]
Anish: Ask the XMLP wg to clarify, when using the SOAP/HTTP binding,
can the response not go in the HTTP response entity body?
ACTION: Hugo to ask the XMLP wg to clarify the issue around the
response in the SOAP/HTTP binding
Kevin: Given WS-Addressing, why don't we just go back to p2 as a
definition of in-out?
strawpoll:
(1) status quo,
(2) in-out becomes p2c,
(3) keep in-out as is, add generalized-in-out p2e,
(4) in-out becomes p2 with conservation of messages
DBooth: (2) and (4) are the same
[kliu: for option 4, the question is - do wsdl mep/iop really need
to
deal with "client" nodes at all?]
option 1: 8
option 2: 2
option 3: 2
option 4: 1
Hugo: Any objections to consensus on option 1?
DBooth: I object because #1 we have been lenient about the meps that
we permit, #2 part two is optional, so it wouldn't be harmful
to add another mep.
Sanjiva: Would you add any bindings?
DBooth: Initially, no
Hugo: Any objections to option 3?
Roberto: Yes
Sanjiva: Asks for a formal vote
[pauld: Found this difficult to follow. thinks in-out should be p2c,
but SOAP-HTTP binding could restrict B and C to be the same
node. is that covered by option (2) ?]
[DBooth: yes, paul, that is option 2]
Hugo: Formal vote on going with option 1 (keeping the status quo)
IBM: yes
Oracle: abstain
WebMethods: yes
SAP: no
Sonic: abstain
RogueWave: yes
Lexmark: no
Sun: yes
W3C: no
BT: no
result: 4 yes / 4 no
Hugo: the issue is not closed
ACTION: DBooth and Anish to clarify what a node is
13:00 Lunch ----------------------------------------
Scribe: kliu
--------------------------------------------------------
13:45 11:15 MEP issues
- Issue LC48b: XMLP Review of WSDL 2.0 Part 2 LC WD (b) [28]
- Issue LC59a: WSDL2.0 Last Call comments (a) [30]
- Issue LC59c: WSDL2.0 Last Call comments (c) [31]
- Issue LC76a: WSDL 2.0 LC Comments (Part 2) (a) [32]
- Issue LC76b: WSDL 2.0 LC Comments (Part 2) (b) [33]
- Issue LC76c: WSDL 2.0 LC Comments (Part 2) (c) [34]
[28] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC48b
[30] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC59a
[31] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC59c
[32] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC76a
[33] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC76b
[34] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC76c
Topic: Issue LC76a
Issue asks for generalize MEP rules to accomdate ws-addressing
DBooth: We should generalize the rule to allow "replyTo". Suppose we
define node in a very generic sense, and allow reply to a
different location
discussion on what's a node
Hugo: Postpone issue till the action of clarify node definition is
available
Topic: Issue LC48b
Sanjiva, Hugo: Resolution should be add something in part 2 to refer
to section 2.3 of part 3
Asir: Should be in both part 2 and 3
RESOLUTION: Add text to part 2 and 3 about WSDLMEP and SOAP mep
mapping that ponts to section 2.3 of part 3
ACTION: Editors of part 2 and 3 to add text about WSDLMEP and SOAP mep
mapping that ponts to section 2.3 of part 3
Topic: Issue 59a
ACTION: Hugo send email about what HTTP request is when in-only is
used
Roberto: If no binding, then no interoperability
Glen: Agree, remove the out-bound operations to a note
Umit: It would be hard for some people
Glen, Roberto: they are hard to test
Kevin: Do we only see wsdl used in the complete sense? does all the
bindings have to be defined in wsdl? See cases that abstract
interfaces contains out-bound operations, bindings are
provided by infrastructure services.
Sanjiva: Not all bindings have to be defined in wsdl. but if
proprietary, they are not interoperable
Asir: We should issue a call for implementations of the outboud
operations
[prasad: But where do you get bindings for these, when WSDL does not
define them]
Hugo: The question is does everything in our spec has to be
interoperable
the proposal from glen: for every mep that we don't have a binding
should be moved to a note
amended by asir: if we don't get implementations/applications that
requires such mep
Glen: Since we already have worked it out and have assigned URIs
for the meps, we should not just get rid of it. keep it in
a note
Prasad: It's ok to keep it in the spec even if we don't have binding
for them. There are already applications that use them.
Sanjiva: If no binding, no interoperation. the uri of the mep can be
definied by whoever needs it
Prasad: It's intentional that binding in such cases are not available
for wsdl
Glen: If we put those mep in a note, we don't have to follow the
rec track requirements
Arthur: Whoever champion the meps should come up with wsdl binding
for them. Otherwise they should be removed
[prasad: But, we did not allow that to happen (in the WG) by limiting
our scope to the bindings we define now]
Umit: Our customers use those meps
[pauld: Over what transport, Umit?]
paul, it could be anything based on the configuration table
ACTION: hugo to check the HTTP bindings really support the MEPs it
claims to support
[Asir: At risk are .. In-Optional-Out and Out-Optional-In]
[Prasad: Plus Out-only and Out-In?]
RESOLUTION: In-Optional-Out and Out-Optional-In will be marked at risk
when entering CR and will be removed unless we see 2
interoperable implementations.
Topic: Issue 59c
Sanjiva: wsdl1.0 is out of question
Charlton: Examples the ws-chor group can show us
charlton presents the CDL examples comparison of MEPS in WSDL1.1 vs
WSDL2.0
one-way --> in-only
request-response --> in-out
notification --> out-only
solicit-response --> out-in
All other wsdl2.0 meps do not have counterparts in wsdl1.1
RESOLUTION: we don't think it's necessary for the working group to work
on it. Expect third party to chime in
Topic: issue 76b
RESOLUTION: editorial. editors bring it back if see issues
Topic: issue 76C
Glen: Don't think we should change the mep
Roberto, davidb, glen...: must be delivered is too strong
Glen: Same case apply to response message
[uyalcina: I think the issue is whether making the delivery of the fault
or response changes the MEP described]
Roberto, davidB, hugo: fault and response are different
[Prasad: SHOULD instead of MUST seems appropriate here. I believe WS-I
BP did the same thing for this situation.]
Sanjiva, Roberto, Glen: must be delivered vs. must be delivered to
binding and transmitted
Hugo: Amy should know
ACTION: Hugo to contact Amy with our interpretation and ask for
clarification
--------------------------------------------------------
15:20 SOAP binding
- Issue LC59b: WSDL2.0 Last Call comments (b) [41]
- Issue LC61e: comments on the wsdl 2.0 working drafts (e) [42]
[41] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC59b
[42] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC61e
Topic: issue LC61e
group is looking at the issue and trying to decide if we want to
tackle it today.
Sanjiva: We already have answers
RESOLUTION: Close with no change to the spec. reply to issue submitter
Topic: issue 59b
[asir: but if you are talking about MTOM, then Glen's e-mail is at
http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0077.html and
http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0076.html]
RESOLUTION: close with no change to spec. we will suport MTOM. SOAP1.1
binding is not part of our recommendation and support for
SwA is not part of our plan
--------------------------------------------------------
15:35 Style issues
- Issue LC61a: comments on the wsdl 2.0 working drafts (a) [51]
- Issue LC74d: I18N Comments, WSDL 2.0 Part I (partial) (d) [52]
[51] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC61a
[52] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC74d
Topic: issue 61a
Hugo: Operation style is move to msg ref
a lot of "what"s in the room
trying to figure out why that change happened and when
Hugo: Uri style is about the message, not about the operation
Glen: One still should be able to do it in operation level
Umit: Agree
it was decided on
http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0042.html
issue lc21
ACTION: Umit to check on operation@style
issue complains style blurs the line b/t interface and binding
Roberto: Styles such as uri style is defined in http binding.
Kevin: Agree with the concern with uri style
Sanjiva: Rpc style should be moved to part 2, same with other styles
Roberto, Umit: rpc style also defines signature, etc. it's different
from uri style
RESOLUTION: Move all the styles and RPC signatures section to part 2.
This address the perception concern, no change to the use
of the styles.
Topic: issue 74d
Glen: We can just not say anything about it (the response name)
[hh-chair: Proposal: drop "The LocalPart of the output element's QName
is obtained by concatenating the name of the operation and
the string value "Response"" from RPC style]
RESOLUTION: close issue 74d as proposed above
--------------------------------------------------------
15:55 More I18N issues
- Issue LC74f: I18N Comments, WSDL 2.0 Part I (partial) (f) [60]
- Issue LC74e: I18N Comments, WSDL 2.0 Part I (partial) (e) [61]
[60] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC74f
[61] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC74e
Topic: issue 74f
Sanjiva: We don't have a glossary
Arthur: We don't have a requirement for glossary
Asir: This is purely editorial
RESOLUTION: close with no change to spec. reply to issue submitter that
we don't have a glossary.if not happen with the definition,
let us know.
Topic: issue 74e
Asir: We should ask one of the editors to come up with a proposed
resolution.
ACTION: Roberto check on comments in 74e and come up with proposal.
Arthur: What about our support for xsd? only 1.0? Can one tell is
an infoset is conformant to a schema?
Asir: We are trying to re-opening issue 177.
Hugo: Time to close the meeting.
Thanks webMethods!
16:15 Ajourn
Received on Tuesday, 16 November 2004 20:50:32 UTC