RE: importing docs in the same namespace

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
> Sent: 04 October 2002 22:19
> To: WS-Desc WG (Public)
> Subject: Re: importing docs in the same namespace
> 
> 
> 
> "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 

I agree that XInclude style inclusion is not sufficient.

>- import has a much more 
> abstract definition than include obviously. 

It is certainly more abstract that XInclude.

>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.)

xsd:include ( like xsd:import ) works at the component level, not the
infoset level. The main differences between the two are as follows:

xsd:import, component based, other namespace, location optional
xsd:include, component based, same namespace, location mandatory
XInclude ( for completeness ), infoset based, same namespace, location
mandatory

The reasoning behind making location optional for xsd:import was that a
given processor may already know about certain namespaces. The reason
behind making location mandatory for xsd:include was that given a
processor is already processing a document with a given targetNamespace
it presumably needs some hint as to how to find the other pieces that
describe said namespace.

I think the cleanest solution is to spec wsdl:import and wsdl:include
the same way the xsd versions work. That way things work the same way in
the wsdl: section of the document as they do in any xsd: sections of the
document.

Gudge

Received on Monday, 7 October 2002 12:26:06 UTC