W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2003

Minutes, 10 July 2003 WSDesc telcon

From: Jacek Kopecky <jacek@systinet.com>
Date: 10 Jul 2003 19:27:14 +0200
To: WS-Description WG <www-ws-desc@w3.org>
Message-Id: <1057858034.8422.77.camel@localhost>



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


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

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
  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:
  Marsh: today our spec doesn't describe much the utility of the various
  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
  IRC: <DBooth>	DBooth's suggested diagrams:
  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
  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
  IRC: <DBooth>	Jacek, I addressed your question a couple of weeks ago in
  IRC: <DBooth>
  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
  DBooth: I thought it was a purely syntax change, assuming chaning both
  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
  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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:31 UTC