- 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