- From: Jacek Kopecky <jacek@systinet.com>
- Date: 10 Jul 2003 19:27:14 +0200
- To: WS-Description WG <www-ws-desc@w3.org>
Attendance
Present:
Erik Ackerman Lexmark
David Booth W3C
Allen Brookes Rogue Wave Software
Youenn Fablet Canon
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Sandeep Kumar Cisco Systems
Philippe Le Hégaret W3C
Amelia Lewis TIBCO
Steve Lind AT&T
Lily Liu webMethods
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Dale Moberg Cyclone Commerce
Bijan Parsia University of Maryland MIND Lab
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
Jerry Thrasher Lexmark
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Regrets:
Roberto Chinnici Sun Microsystems
Dietmar Gaertner Software AG
Steve Graham Global Grid Forum
Kevin Canyang Liu SAP
Ingo Melzer DaimlerChrysler
Jean-Jacques Moreau Canon
Arthur Ryman IBM
Adi Sakala IONA Technologies
Prasad Yendluri webMethods, Inc.
-----------------------------------
1. Assign scribe
scribe: JacekK
-----------------------------------
2. Approval of Minutes [.1]
[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0041.html
minutes approved
-----------------------------------
3. Review of Action items [.1]
PENDING 2003-03-13: Don will write a proposal for annotating schema with part
information.
PENDING 2003-03-27: Philippe write up a proposal for embedding binary data
types in schema
PENDING 2003-05-13: DaveO to send a motivating example for R131.
PENDING 2003-05-13: Jeffsch, Sanjiva, Glen, Umit, JJM to come up with a
proposal to get rid with the message construct, and add
programming hints.
PENDING 2003-06-12: Jacek to synthesize the different approaches to solving
issue 64.
DONE [.2] 2003-06-26: dbooth to propose definitions for "interface",
"service", etc. as they pertain to the diagram
PENDING 2003-07-03: Arthur to figure out which validation mode our schema
should specify on xs:any.
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0018.html
-----------------------------------
4. Administrivia
Marsh: not many people have been registering
Marsh: September meeting logistics page coming up
-----------------------------------
5. TF status
the MEP TF has not yet gotten to the WS-A material on MEPs
-----------------------------------
6. New Issues
Marsh: ATM suggested a service resource - a collection of associated
services
DBooth: it's related to the terminology
DBooth: we can take this up under the terminology & diagram topic
Marsh: there was a question about the meaning of multiple schema elements
in <types> section
IRC: <jeffsch> wsdl12.xsd doesn't seem to constrain the contents of
wsdl:types much.
Jacek: I don't think there is an issue here, either XML Schema handles the
possibility of multiple clashing definitions, then we should point to that,
or XML Schema punts on it, we should do likewise then
Marsh: so we won't track this one as an issue
Marsh: what do we name our spec - 1.2 or 2.0? We should track this issue
and maybe take it up after some major stuff we have in pipeline
-----------------------------------
7. Terminology and Diagrams
DBooth: we don't really know how the terminology relates to the current
terminology, or if we have multiple terminologies
IRC: <philippe> and what about http://www.w3.org/TR/ws-desc-reqs/#normDefs ?
DBooth: I tried to explain the meaning of WSDL constructs and the
relationships between them
Marsh: so, have we redefined the term service?
IRC: <jeffsch> The requirements seem like a reasonable place to put
definitions that the WG needs to agree on.
Philippe: we have definitions in the requirements draft, we spend a fair
amount of time on those
IRC: <jeffsch> But we should put definitions in Part 1 when we need the
world as a whole to see / understand them.
DBooth: we might copy them to the core part
Philippe: we should try to find the differences between what david proposed
and the requirements definitions
IRC: <DBooth> requirements definitions:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/requirements/ws-desc-reqs.html#definitions
Marsh: today our spec doesn't describe much the utility of the various
constructs
DBooth: firstly I wanted us to have correspondence between the terminology
and syntax
DBooth: secondly I wanted to describe the relationships between them
Marsh: I haven't seen an attempt to change terms or add new terms - is the
list of terms adequate?
Marsh: in the requirements doc we don't have the target resource
Marsh reads david's defn of target resource
Marsh and david discuss the case where the service is the same as the
target resource
Marsh: is there a proposal for targetResource renaming?
someone: serviceTarget?
TomJ: weren't we discussing it before?
voices for avoiding the term 'resource'
strawpoll: targetResource or serviceTarget?
Marsh: majority for serviceTarget
Marsh: any objections on changing the name to serviceTarget?
TomJ: isn't this tied to single interface per service?
Jacek: I think not
ALewis: I agree with Jacek
Marsh: I think we found it to be orthogonal
ALewis: we will file a minority opinion on this topic
ALewis: anyone else who wishes to join, please contact me
ALewis: there is an associated email from about the binding simplification
proposal, it seems to be lost
Marsh: we will try and talk about the binding simplification proposal
shortly
IRC: <DBooth> DBooth's suggested diagrams:
http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0019.html
Marsh: let's move on to the diagram
DBooth: the diagrams in our spec don't seem to reflect the reality
DBooth: there was a direct connection from interface to resource, the
syntax has a connection from a service to a resource
DBooth: the connection is indirect
Marsh: the diagrams mix things concrete with things abstract
IgorS: service target sounds like the client - the service is targeted at
the client
TomJ: now that igor points that out, I see it, too
Umit: after renaming targetresource to serviceTarget the diagrams are more
confusing
Jacek: we don't seem to have a clear meaning of the attribute
TomJ: it's helpful for discovery
DBooth: we could remove the manipulation from the definition
DBooth: discovery is the only reason for targetResource
Bijan: there may be inadvertent implications in this attribute
Jacek: if we have an unknown relationship, it doesn't help discovery
DBooth: it doesn't
Tomj: we seem to be going down a rathole, I thought we added the attribute
to preserve the functionality WSDL 1.1 gives us
Tomj: to group different services
IRC: <Marsh> Should we call it serviceGroup?
IRC: <bijan> I'm about to suggest something like that :)
Jacek: WSDL 1.1 had two relationships, one the alternativity of ports,
second this abstract relationship
Jacek: we want to describe the relationship or lose it
IgorS: I think the intention was to keep the functionality of WSDL 1.1
Jacek: WSDL 1.2 wants to clean up WSDL 1.1, too
IRC: <alewis> "Portions of the same service" ?
Bijan: what are you trying to discover through targetResource?
Tomj: in 1.1 we had a slew of ports in a single service
Tomj: you can't do that in 1.2 (2.0)
Tomj: so we invented targetResource, purposely vague
IRC: <igors> I totally agree with Tom!
DBooth: igor may be confusing discovery and description
DBooth: discovery needs description, not the other way around
IRC: <bijan> Can undefined "manipulate" mean "manipulates something else
altogether, ha ha ha"? :)
IRC: <Marsh> Manipulate: to manage or utilize skillfully. (m-w.com)
Jacek: I don't want vague definitions admitting they don't define
IRC: <Marsh> Manipulate: to change by artful or unfair means so as to
serve one's purpose
Marsh: maybe we could have explicit grouping, or we can have more specific
"manipulating"
IRC: <DBooth> Jacek, I addressed your question a couple of weeks ago in
http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/0093.html
IRC: <DBooth>
http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/0094.html
IRC: <DBooth> s/question/issue/
Tomj: maybe we can have both
Tomj: arguing for status quo before our todays renaming decision
DBooth: serviceGroup, for example, hints to the need of us specifying the
relationship of multiple services in one <definitions> element
IRC: <Tomj> I don't think we need to specify implied service group (all
services in the same WSDL definition), if users want to do that fine.
Marsh: do we want to change resource to something else in the diagram?
IRC: <jeffsch> +1 to revise diagram and/or description to match
serviceTarget
DBooth: I thought it was a purely syntax change, assuming chaning both
places
Marsh: do we want to change the diagram to match the current name?
Marsh: do we want to targetResource (and resource in diagram) or
serviceTarget (and target, maybe?)
Marsh: we might want to name it serviceGroup and "grouping services" would
be all that could be implied from the relationship
Jacek: I'd be happy with that
Tomj: I'd be especially happy if it would appease the issues of other
people
Marsh: reconducting the straw-poll
IRC: <igors> I'm +1 to targetResource attribute AND +1 to <serviceGroup>
element :)
Marsh: our last decision was tentative, we will continue the discussions
and pursue serviceGroup
IRC: <Tomj> I am not in favor of a new serviceGroup element. Yuk,
IRC: <jeffsch> Editors will not add this to the TODO
IRC: <Marsh> Marsh is encouraged our productivity is increasing. We made
two decisions today! Too bad one revoked the other...
Received on Thursday, 10 July 2003 13:27:18 UTC