"Martin Gudgin" <mgudgin@microsoft.com> writes:
>
> You could use XInclude to do that, I think we talked about that approach
> in Paris. Or we could define a wsdl:include with the same semantics as
> xsd:include ( sans chameleon include, probably ) ( I know we already
> decided not to define wsdl:include).
>
> >
> > So, I believe this should be another case of how
> > we diverge from XSD import semantics.
>
> Apart from requiring schemaLocation what are the other cases where we
> diverge?
In WSDL 1.1 the XSD-like-import semantics were chosen because
that was presumed to do the right thing for what WSDL needed.
However, if it doesn't, then I see absolutely *NO* reason for
retaining that similarity.
I don't think inclusion is what we need - import has a much more
abstract definition than include obviously. Without import I cannot
handle the scenario where I want to include 2 WSDL docs- both defining
types/messages/portTypes and then define bindings and a service. (We'd
end up with two <types> sections; not legal.)
I'd like to get back to the original problem: WSDL 1.1 had a certain
authoring style which was prominently indicated by the spec. However,
it turned out that the statement "it works like" schema was incorrect
w.r.t. that authoring style. Note that even the original UDDI/WSDL
best practices document used precisely that split.
I think we should throw away the "it works like XSD import except
that the location is required" and just define our own semantics
which allows importing documents from the same namespace.
Sanjiva.