- From: Jacek Kopecky <jacek.kopecky@systinet.com>
- Date: Fri, 03 Oct 2003 18:12:17 +0200
- To: WS-Description WG <www-ws-desc@w3.org>
W3C Web Services Description Teleconference 2003/10/02
Minutes of Meeting
Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0260.html
--------------------------------------------------------------------
Roll Call
--------------------------------------------------------------------
Present:
Erik Ackerman Lexmark
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Paul Downey British Telecommunications
Steve Graham Global Grid Forum
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Philippe Le Hégaret W3C
Amelia Lewis TIBCO
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jean-Jacques Moreau Canon
Bijan Parsia University of Maryland MIND Lab
Adi Sakala IONA Technologies
Jeffrey Schlimmer Microsoft
Jerry Thrasher Lexmark
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Regrets:
Youenn Fablet Canon
Dietmar Gaertner Software AG
Lily Liu webMethods
Ingo Melzer DaimlerChrysler
Arthur Ryman IBM
Prasad Yendluri webMethods, Inc.
Scribe:
Jacek Kopecky
--------------------------------------------------------------------
2: Approval of minutes
--------------------------------------------------------------------
minutes accepted, with correction for components designators on one f2f day
--------------------------------------------------------------------
3: AIs:
--------------------------------------------------------------------
3. Review of Action items [.1].
? 2003-07-31: Philippe to make a proposal for fixing the
HTTP binding.
DONE [.5] 2003-09-04: Jacek to review Appendix E in light of message
removal.
? 2003-09-11: Philippe to write a response to Mark Baker
proposing a property solution to HTTP verbs
and ask whether this satisfies his request.
DONE [.2] 2003-09-18: Jonathan to put 1.2/2.0 item on FTF agenda.
DONE [.4] 2003-09-18: Dbooth to ping amy on whether she is satisfied
that the current patterns draft adequately
permits multicast.
DONE [.2] 2003-09-18: Jonathan to put #89 on FTF agenda.
? 2003-09-18: Philippe, Marsh to review the QA operational
guidelines.
DONE [.3] 2003-09-22: 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.
RETIRED 2003-09-22: Potential editors for media-type schema
annotation to apply to Chair.
DONE 2003-09-23: Philippe to recommend the wsdl 2.0 name to
Director.
? 2003-09-23: Roberto, Glen: provide a counterproposal to
the current proposal for endpoint references.
CLOSED 2003-09-23: ATF to describe for these style uri for
attributes.
CLOSED 2003-09-23: Core editors to include those rules in the
draft.
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0140.html
[.3]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html#RPCS
tyle
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0137.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0136.html
--------------------------------------------------------------------
4: Administrivia
--------------------------------------------------------------------
Topic: upcoming f2f
Marsh: administrivia soon to be available
Marsh: next plenary we'll see with whom to overlap with our 2-day f2f
Philippe: plenary f2f meetings are usual open to observers
Marsh: probably by the next week we'll know which part of the plenary week
we'll meet
Topic: publication plan
sanjiva: we might be ready in a week or two (at least part 1)
[roberto: +1]
alewis: patterns will be a few hours of work after the decisions are made
alewis: I can do everything by next Mon or Tue
Marsh: let's let the editors prioritize our agenda today
umit: how about the attribute rules?
sanjiva: RPC rules are there, the other two styles for attributes aren't
there yet, we can publish without them
umit: we have more rules to be added to attributes
Marsh: we don't need to solve all issues before we publish, if your rules
are controversial, we may want to wait after publication
Marsh: editorial-type improvements are easy
jeffsch: the HTTP binding is piled on Philippe, we might want to put in a
caveat
jeffsch: what are the external requirements for publication? The hart-beat?
sanjiva: would like to publish parts 1 & 2 as a way to indicate more
closure on that so that he (for example) can get wider review inside
IBM on those parts.
Marsh: we will leave it to the editors whether we publish part 3 or not
Marsh: is updating part 3 a "bounded" problem? Could it be done in a
couple of weeks?
[sanjiva: I'd like to see us publishing parts 1 & 2 ASAP, but a couple
of weeks is ok. If its longer I'd like to go ahead with the first 2
parts.]
jeffsch: would we like to have the group double-check and review it?
jeffsch: the editors will do what we can, putting notes around stuff that
we know is incomplete
jeffsch: in october all SOAP stuff will be complete, in January all will
be completed
[Philippe: Publishing moratoria:
http://lists.w3.org/Archives/Member/chairs/2003JulSep/0056.html]
Marsh: let's vote on publishing in two weeks
Marsh: so in cca ten days we'd like to have drafts for review
Marsh: next two telcons will be chaired by someone else than me
Marsh: we're still looking for editors of media-types note
Marsh: looking for someone (a schema expert) who is interested in it
[sanjiva: Philipe: You might want to ask Chris Ferris about helping with the
media-types thing .. he's a big schema bigot^H^H^H^H^Hexpert]
--------------------------------------------------------------------
6: New Issues
--------------------------------------------------------------------
Youenn had a proposal on layered MEP defs; new issue
jeffsch: how do we mark features as accepted or required?
Marsh: to be tracked as an issue for now
[jeffsch: Youenn's issue will be Issue 92]
mark baker started a thread on bulk load
[sanjiva: +1 for rejecting bulk load quickly]
Marsh: do we have a champion for standardized bulk load?
[jeffsch: Strongly in favor of rejecting bulk get / set.]
sgg: don't see how we could do that
Marsh: sanjiva's removal proposal retracted
Marsh: wsdlLocation discussion
Marsh: is it in the next round of publication?
Marsh: won't track that, will be handled in the future
Marsh: sanjiva: the uniqueness constraints are not checkable
sanjiva: we can only enforce this in a single WSDL document
alewis: presumably, when you have multiple WSDLs for the same namespace,
you have mechanisms for resolving convflicts
alewis: so it's a cataloguing problem, isn't it?
alewis: we should make note of the problem of namespace resolution
dbooth: the same WSDL document is the one component model
jeffsch: currently, a wsdl processor doesn't care about WSDL documents
that are not loaded
dbooth: how do you know it's a problem and not versioning?
roberto: agree with Amy
roberto: I don't think our spec should go further than have a note
Marsh: we seem to be in agreement, let's go to the concrete text
dbooth: we can say that if one QName is used in different documents, it's
assumed to be the same
jeffsch: we may say it's undefined and note that other specs (for
environments) may say something
sanjiva: we can add a good practice note
alewis: this is out of scope for WSDL, the best we can do is suggest if
you get the wrong doc, you may be in trouble
[roberto: +1, it's out of scope]
Marsh: maybe we can move on
[sanjiva: I'm happy with leaving this unspecified .. its not a big
enough deal and I'll continue to answer "don't do that"]
Marsh: is it important that we do something?
[jeffsch: Put it in the primer?]
[sanjiva: +1!]
Marsh: we will record issue against the primer for this
[jeffsch: It will be issue 93]
--------------------------------------------------------------------
8: Patterns
--------------------------------------------------------------------
Marsh: at the f2f we have marked the multi- patterns as at risk; Amy
doesn't require them, any other champion for them?
Resolution - those two patterns removed from the spec without objections
Marsh: do we add others?
Marsh: maybe support pub/sub better?
alewis: I'm submitting a list of 3 patterns, useful for pub/sub, two also
elsewhere
alewis: input-only, input-output and output-input with message-triggered
faults
alewis: we're not talking about synchronous communications
Marsh: do these MEPs meet our criteria? Are the criteria a consensus?
Marsh: we've had multiple criteria proposed for including MEPs
Marsh: adding these MEPs would demonstrate the use of one rule we have in
the MEP framework - the message-triggered faults
Kevin: I'd like to go to higher-priority things
alewis: in the past months we've clarified a lot about MEPs
alewis: adding a pattern is not expensive
alewis: we could improve part 2 by adding a use-cases clause to each
pattern
umit: why not put the use-cases in the primer?
Kevin: I'm not saying these patterns aren't useful, but can we go without
these patterns? We could wait until later for working on more
patterns.
roberto: adding normative patterns is expensive
roberto: tools are expected to support all normative parts
roberto: if we remove the MEPs later, it's gonna be expensive, too
roberto: I propose that additional patterns should go into a non-normative
section
sanjiva: we have decided we don't only want to keep the patterns we have
bindings for
sanjiva: we're only providing the URIs; unless a binding uses them, tools
need not support them
[alewis: +1 to Sanjiva's comments.]
[dbooth: +1 to Sanjiva]
roberto: tools that use the abstract level need to support all normative
patterns
sanjiva: I agree, part 1 has to be written so that the abstract level
stops at a pointer to the pattern
roberto: it cannot be done, the pattern shows in the operation component
in the abstract level
jeffsch: a compliant implementation need not implement all of WSDL 2
roberto: this case is somewhat different from the case with bindings
jeffsch: generally, we define normatively things (like bindings, MEPs,
operation styles) but don't require the implementations to supoprt
them
roberto: shall we say explicitly that an implementation MAY ignore some
patterns?
jeffsch: in this case it may be necessary to be explicit about it, yes
jeffsch: we may need to have a category of things that are extensions
jeffsch: a processor should not die when encountering an interface it
doesn't use that uses unknown MEPs
roberto: it would be expected that all implementations implement all
normative things, otherwise what's the point in normative vs.
non-normative distinction?
jeffsch: I'm supporting us being clear about this as there are different
expectations, we should add some wording about it
Marsh: is normative/non-normative distinction confusing?
Marsh: would a marking in the added patterns that they may not be
implemented satisfy Roberto?
roberto: yes
Marsh: we're really only defining URIs so that other people can have a
common place to build functionality on
Marsh: could the criterion for accepting patterns be that they are
shareable by multiple different bindings?
alewis: these bindings would meet the criterion
alewis: I'll include in the submission where these MEPs might be useful
alewis: I'll include examples from other WS-* committees
jeffsch: I suggest patterns URIs are like styles, bindings, we don't
require any of them being implemented; market pressures may cause
most or all of them implemented in most implementations
[alewis: +1 to Jeff's formulation.]
[dbooth: +1 to JeffSch's comments]
dbooth: My opinion: We should not require a WSDL-conformant processor
to recognize/implement every pattern, just as we cannot require every
WSDL-conformant processor to recognize every possible app-specific
interaction pattern.
dbooth: I think we're talking about two different levels of interop:
(1) message-level app interop (ESSENTIAL); and (2) tool interop (NOT
essential).
dbooth: If two parties (requester and provider) agree to interact
using a particular WSD, it is important that they have the SAME
understanding of the meaning of that WSD. (I.e., message-level app
interop.)
dbooth: This is NOT the same as requiring different tools to have the
same behavior when presented with the same WSD. (I.e., tool interop.)
dbooth: If we are in agreement that an implementation is not REQUIRED
to support every pattern, then we should be generous in our
publication of pattern URIs.
umit: WS-I will normativize the non-normative extensions
[alewis: patterns *are* extensions.]
umit: there is a difference between optional and extensions
[jeffsch: I wonder whether Umit sees support for patterns and/or styles
as comparable to bindings?]
umit: this will require profiling
[alewis: And WS-I is a *good* organization to pick up and *recognize*
best practice, after we've given people the opportunity to work it
out *in practice*.]
[jeffsch: +1 to alewis]
dbooth: I believe we SHOULD specify EXACTLY what each pattern means,
and say that if the pattern is USED, then we specify PRECISELY the
meaning.
kevin: +1 to umit
[alewis: +1 to David's comment on what it means for a pattern's
semantics to be normative, though the patterns themselves are not.]
kevin: if the MEPs are optional, how can I be sure I can talk to others?
[sanjiva: I think the mapping from the pattern URI to the rules for
that pattern is indeed normative. That is, someone cannot take one of
our pattern URIs and have different semantics for it. What's not
normative is whether a processor MUST support/recognize a given
pattern! I agree WS-I is a good place to sort that out *after* people
have used and loved certain patterns.]
kevin: when I use an optional MEP,I can't be sure the other side will
understand it
[dbooth: kevin, you can NEVER be sure that you can talk to someone
else. You can ONLY talk to someone else if you both agree on BOTH the
WSDL *and* the semantics of the app. If you can't agree, you can't
interact. Period.]
roberto: I don't see how we can go allowing pretty much anything in the
spec if we just say it's all optional
Marsh: running out of time, will continue on email...
[alewis: that was argumentum ad absurdam ....]
[umit: +1 to roberto]
Marsh: Amy, we want to see the description of your proposed patterns
[roberto: that's a valid proof technique :-)]
Marsh: Amy suggests changing broadcast to multicast, objections?
Resolution to do that change passed with no objections
[jeffsch: Agree with Roberto that we can't allow pretty much anything
into the spec.]
[alewis: I think it might help to inform the arguments if we have some
specific patterns, including use cases, so I'll provide them.]
[alewis: ACTION: alewis should provide write-up of additional patterns
for further discussion]
[alewis: ACTION: part 2 editors to replace "broadcast" with
"multicast" in descriptive text]
Marsh: sanjiva suggested we could merge parts 1 and 2; he's dropping this
proposal, any other champion?
Marsh: item dropped
--------------------------------------------------------------------
Marsh: I'll work on a chair for next week
meeting adjourned
--------------------------------------------------------------------
Summary of actions:
--------------------------------------------------------------------
PENDING 2003-07-31: Philippe to make a proposal for fixing the
HTTP binding.
PENDING 2003-09-11: Philippe to write a response to Mark Baker
proposing a property solution to HTTP verbs
and ask whether this satisfies his request.
PENDING 2003-09-18: Philippe, Marsh to review the QA operational
guidelines.
PENDING 2003-09-23: Roberto, Glen: provide a counterproposal to
the current proposal for endpoint references.
NEW 2003-10-02: Amy: provide write-up of additional patterns
for further discussion
NEW 2003-10-02: Part 2 editors: replace "broadcast" with
"multicast" in descriptive text
Received on Friday, 3 October 2003 12:12:20 UTC