Re: importing docs in the same namespace

"Martin Gudgin" <mgudgin@microsoft.com> writes:
> 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

Thanks for this info .. very useful at least for me!

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

What was the rationale for using two different language constructs
for the two cases? It seems to me that import with location
requiredness defined in terms of the namespace (same or not)
would work just fine. 

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

Assuming that you guys had good rationale for creating two different
constructs for the two cases in XSD, I would have to agree.

I was against <include> earlier on the basis that one import/include
mechanism has been sufficient in programming languages (java, c#, c++, 
etc.). Java for example does not require imports for stuff
in the same package (namespace) - however, the location is 
implied in that case .. so the analogy isn't exact. My personal
preference would be to use one construct with location requiredness
defined in terms of namespace sameness, but the XSD experience
seems to have some reasons for not going that way.

Sanjiva.

Received on Monday, 7 October 2002 12:44:33 UTC