- From: Antoine Mensch <antoine.mensch@odonata.fr>
- Date: Wed, 14 Oct 2009 21:59:48 +0200
- To: Doug Davis <dug@us.ibm.com>
- CC: public-ws-resource-access@w3.org
Doug, let me try to clarify (see below) Cheers Antoine Doug Davis a écrit : > > I'm still not totally clear on the exactly scenario here because it > feels a bit like there are certain assumptions being made. For example, > it sounds like people are assuming that a single WSDL file is enough > to get their work done. And while its possible to create a single WSDL > file that contains everything, its also possible that someone could > design > things so that the WSDL is split into multiple files, and the schema > isn't > part of the WSDL at all. This means that unless you're going to > require that > everyone design their WSDL is one particular way, then you need to be > prepared > to deal with retrieving mulitple files - whethers its WSDLs, XSDs or > Event > Descriptions. And, likewise, any relationship between these various > artifacts would have to be expressed somehow - even if implicit because > they were all sent in one package. So, to me the relationship to the > portTypes you're referring to can still be achieved at design time. But > I suspect I'm still missing something. > > The issue is not related to the way WSDL information is organized or to the number of documents used to hold the information: I assume (like most tools do) that there is a master WSDL document that can import or include additional WSDL or XSD documents using both namespace references and absolute or relative URIs (note however that I don't know how I would include or import an Event Descriptions document from a master WSDL, unless it is embedded in some way in a WSDL - but that's only a minor part of the issue). Rather, the issue relates to the lack of logical relationship between the WSDL information model and the event types. A WSDL defines a number of objects (endpoints, services, bindings, portTypes, operations, messages) that are linked by navigable relations, so for instance it is possible to know the set of operations and messages supported by an endpoint by navigating from the endpoint to its binding and its portType. The previous version of the spec used Notification and Solicit/Response operations (that are built-in WSDL objects) to describe event types, so the built-in WSDL relations could be used to relate a portType or an endpoint to the events it would generate. Because the new version of the spec introduces new objects in the information model without defining a way to relate them to existing WSDL objects, it is impossible to use the WSDL to relate portTypes or endpoints to event types. So my suggestion was just to add a way to relate the new event types to existing WSDL objects, and in particular to portTypes, which seems the appropriate concept (event types, which are abstract, can be seen as part of the interface of a service, much like operations are). > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.421 / Virus Database: 270.14.15/2434 - Release Date: 10/13/09 19:11:00 > >
Received on Wednesday, 14 October 2009 20:00:21 UTC