Present: David Booth W3C
... Allen Brookes Rogue Wave Software
... Roberto Chinnici Sun Microsystems
... Alan Davies SeeBeyond
... Youenn Fablet Canon
... Jacek Kopecky Systinet
... Philippe Le Hégaret W3C
... Amelia Lewis TIBCO
... Steve Lind AT&T
... Jonathan Marsh Chair (Microsoft)
... Ingo Melzer DaimlerChrysler
... Jeff Mischkinsky Oracle
... Dale Moberg Cyclone Commerce
... Jean-Jacques Moreau Canon
... Bijan Parsia University of Maryland MIND Lab
... Arthur Ryman IBM
... Adi Sakala IONA Technologies
... Jeffrey Schlimmer Microsoft
... Igor Sedukhin Computer Associates
... Jerry Thrasher Lexmark
... William Vambenepe Hewlett-Packard
... Sanjiva Weerawarana IBM
... Umit Yalcinalp Oracle
Regrets: Glen Daniels Macromedia
... Dietmar Gaertner Software AG
... Steve Graham Global Grid Forum
... Tom Jordahl Macromedia
... Sandeep Kumar Cisco Systems
... Lily Liu webMethods
Chair: Jonathan Marsh
Scribe: Ingo Melzer
Scribe: Minutes of W3C WSDWG Conference Call, 12 June 2003
Scribe: 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
... PING'D 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-05-14: Kevin to contact Sanjiva and try to merge proposals.
... RETIRE 2003-06-05: Jonathan to see what language for testable
... assertions should be used by the editors.
... DONE [.2] 2003-06-05: Jeffsch to show how testable asssertions would look like.
... DONE [.3] 2003-06-05: Editors to publish 1,2,3
... PENDING 2003-06-05: Jonathan to see what is the problem with substgrps.
... ACTION: Bijan to look at test assertions in RDF
<Philippe> CVS sources: http://dev.w3.org/cvsweb/2002/ws/desc/wsdl12/
... Guide to XMLSpec: http://www.w3.org/XML/1998/06/xmlspec-report.htm
... Arthur: please add an id attribute on the assert element.
... -> <!ATTLIST assert id ID #REQUIRED>
Scribe: Welcome Jim Hendler (no present today)!
... July FTF has been moved to Raleigh.
... ACTION: dbooth to get F2F registration page up and update logistics page
Scribe: More people for patterns task force needed.
<Philippe> Attributes TF minutes: http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Jun/0011.html
... minutes MEP TF: http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jun/0008.html
... GGF IP: http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Jun/0012.html
Scribe: Problems with HTTP is relevant to issue 64.
<Philippe> relevant to issue 64: http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/0006.html
<Philippe> (targetResource attribute)
<Philippe> targetResource discussion
... The targetResource attribute information item identifies the resource
... that can be manipulated through the service's interface. (proposal from Jean-Jacques)
<Arthur> Proposal: it is useful to regard an endpoint as acting on some resource. the precise details of the relation between the endpoint and the target resource is application dependent.
... If two or more endpoints act on the same target resource, they can be placed in the same <service> element
... If two or more <service> elements act on the same target resource, they can be explicitly related by the @targetResource attribute
<Philippe> Jacek: [...] we maybe want: "if you have the same targetResource and the same interface, then they are interchangeable".
... Jacek: disagree that semantic of the service is identified by the targetNamespace of the service. Just used for namespacing. If the same qname, then then do identified the same thing.
jeff: targetResource: purpose is to be able to identify the thing behind the service. targetNamespace is orthogonal.
<Philippe> jeff: two services working on the same resource may have different semantic
... jeff: happy with JJM proposal
... Jonathan: 2 proposals: David and Jean-Jacques
Scribe: David can live with JJ proposal.
<Philippe> David: didn't change my mind. The term manipulated through is abiguous but won't cause any harm. It's ok to go with JJM proposal. We may be precluding valuable uses of the targetResource unnecessarely.
Scribe: Additional information always needed about "thing" behind an interface.
<Philippe> Jonathan: the targetResource has a built-in role: two services with the same tergetResource are different ways to manipulate the same thing
Scribe: For now we will use JJM's suggestion.
<Philippe> jeff: let's move with JJM proposal and revise it if we're missing an important use case.
<Marsh> The targetResource attribute information item identifies the resource
... that can be manipulated through the service's interface.
... JJM's wording: "<revised>
... The targetResource attribute information item identifies the resource
... that can be manipulated through the service's interface.</revised>"
<Philippe> ACTION: part 1 editors to change the wording for targetResource with JJM proposal
Scribe: Jonathan not done with item 7.
... It will be delayed until next week.
Jonathan: Questions about aggregation?
<Philippe> Igor: agregation: when I want to do, was pretty straight forward before.
... nothing between targetResource and inheritance works fine with WSDL 1.1 ...
... Sanjiva: if the service does one set of things, then inheritance allows us to define that set of things. If it also uses another set, then inheritance may not be the solution, agree with that. But, in that case, they're acting on the same resource.
... ... in your case, if 2 set of related functionalities, the way is to use the same targetResource URI. Very clean semantic and better than WSDL 1.1
... Sanjiva: Java has classes and interfaces. Class can implement multiples, but implicitly has one interface, which is the aggregation of the multiple interfaces.
... Sanjiva: the way we define inheritance is really a union.
... Igor: concrete case. I have inheritance with 2 endpoints, those 2 endpoints have to bind the whole interface or partially.
Scribe: Question: Inheritance with two endpoints. Binding to both endpoints nec.?
<Philippe> Sanjiva: can't do that. Can't do partially. All endpoints must support all operations.
... Igor: so for every binding, I have to know inheritance for all cases.
... Igor: I have to be specific in the binding.
... Sanjiva: we have that today anyway
... Sanjiva: even with inheritance, you have to support all operations from inherited interfaces.
... Amy: I think we loose things here and didn't gain anything.
Scribe: Problem about combining two or more services as one.
<Philippe> Sanjiva: not a tooling problem. It's about providing a very precise semantic to what a service is.
<bijan> That was my question :)
<Philippe> diagram: http://www.w3.org/TR/wsdl12/Service-Resource.png
... and http://www.w3.org/TR/wsdl12/Service-Resource2.png
... Sanjiva: the diagram provides a high level of all concepts in WSDL
... Sanjiva: syntax is another issue, but we need to agree on the diagram first.
... Sanjiva: we talked about several serialization ways
... Diagram from the f2f: http://www.w3.org/2003/05/wsd-pics/dcp_4975.jpg
Scribe: Amy and Igor will write an email about the problem with the diagrams.
<Philippe> Umit: http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/att-0005/WS-Ref3
Umit: Different ways of fomulating web service references.
Scribe: Ways for interjecting interface and binding informaiton
Umit: gave 3 alternatives for the use of XPATH.
Scribe: Umit's recomendation is option 1
<Philippe> Arthur: the second part (dynamic run time recognition of references) was beyond the scope of my proposal. it's more in the WS-Addressing proposal.
... Umit: pretty much similar to IOR
... you can put more properties in that reference, but the service element is what the reference should be
... Arthur: the ability of a client to invoke will depend on the bindings supported.
... Umit: they will be available in the service element concept
Umit: Binding informaiton not nec. to make us of an reference.
Scribe: Question about using binding information at run-time.
Arthur: Umit's proposal not neccesary in a static case.
<Marsh> Arthur: Doesn't like the coupling between Umit's proposal and XML Schema.
Scribe: Confusion about the arguments of Umit and Arthur.
... ACTION: Summury of Arthur of his concerns by email.
<Arthur> Umit is recommending (I) in her document.
... That replaces XPath with creating an XSD type to "tag" the reference.
... The type only needs to be unambiguous in the context of the message part.
... Therefore if a message just has one kind of URI, there is no confusion, so why introduce new types?
<umit> a URI is not enough to describe a reference. By itself, a URI does not represent a webservice reference.
<Arthur> If there are two or more URIs in a message, then you can define a new type for each, but there is no need for them to derive from some common WSDL type that simply wraps anyURI
... A URI is all you need in the static case which is what R085 is about.
<umit> We are proposing a format which can be used statically and dynamically.
<bijan> What's the extra part of a "webservice reference" over an URI
<Arthur> The new format is just verbose for the static case.
... Also, why not allow XLINK type references?
<umit> Conceptually a ws-reference is different than a URI. This proposal makes this explicit, allows the reference to be a first class concept.
<bijan> I believe that they're different. I'm asking (perhaps for a pointer) to exactly what constitutes the difference. In a nutshell :)
<Jacek> ACTION: Jacek to synthesize the different approaches to solving issue 64
Scribe: Philippe, thanks for helping!