use case for evaluating import/include semantics

The semantics of <import> in wsdl seems (from the discussion in the latest
WD and on this list) somewhat uncertain; it is also unclear whether there
will be an <include>, and what it would mean.

Here is a use case that may help the working group sort out these issues.

Consider a reasonably generic web-service invocation component (such as the
WSIF DynamicInvoker sample client).  It takes the specification of a WS
operation with a set of appropriate input parameters, and returns some form
of result, which may be the desired result or a fault object.  To keep it
appropriately generic, it could take all its parameters as either strings
representing items of simple type or DOM Elements representing items of
complex type.

The client of such a component need know nothing of WSDL -- all it needs is
to know the types of the input objects and the result.  For instance, in
passing back the result, the generic invocation component needs to provide
the string or Element, the QName of its type, the schema location of the
type's definition, which may be useful to the client in determining how to
deal with that result, and perhaps an indication of whether the object was
in an output or a fault message body.

For this use case, then, it suffices for the generic invocation component to
be able to provide the namespace and schema location for every part of every
message appearing in one of the operations of the service.  The WSDL
processor built into this generic component presumably can access all these,
through whatever chains of wsdl:import and xsd:import or xsd:include might
occur.   It should not be necessary for the generic invocation component to
know how to do this.

Thus, the WSDL specification should provide information items for the types
appearing in all the messages, namespace and schema location, and these
information items should be accessible from outside any WSDL processing
component.

Owing to the possibilties of WSDL imports which refer to either schemas or
other wsdl documents which contain or import schemas, a uri fragment
notation must be devised to represent the location of the schemas which are
not top-level elements in their respective files.  Probably an
XPointer-style notation in the form of uri#fragment where fragment might be
something like
xpointer(/wsdl:definitions/wsdl:types[3]/xsd:schema) or
xpath(/wsdl:definitions/wsdl:types[3]/xsd:schema) could be used.

The generic invocation component can pass these items on to the client,
which needs only an xpath processor and a generic xml parser to be able to
rummage around in the relevants schemas.

Jeff Greif
Webalo, Inc.

Received on Friday, 18 October 2002 22:34:14 UTC