RE: Minutes, 10 July 2003 WSDesc telcon

Although we didn't record these actions explicitly in the minutes, I would like them to be noted:

2003-07-10: DBooth to reconcile his terminology with that in the requirements doc.

2003-07-10: Jonathan to send a summary of the @serviceGroup idea to the list.

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
> Behalf Of Jacek Kopecky
> Sent: Thursday, July 10, 2003 10:27 AM
> To: WS-Description WG
> Subject: Minutes, 10 July 2003 WSDesc telcon
> 
> 
> 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 Friday, 11 July 2003 13:34:54 UTC