Re: What is the meaning of the import statement?

"Milan Trninic" <mtrninic@galdosinc.com> writes:

> I've been pondering on one issue related to the multiple <import>s of the
> same namespace. Here is the story in short:
> 
> I wanted to modularize the definitions in our namespace and to import them
> selectivelly from the application schemas. (Application meaning the schemas
> built on top of our base schemas). And I've figured I can't since the
> specification allows processors to ignore all but the first <import>
> statement of the particular namespace.
> 
> On the other hand, the specification allows processors to take into the
> account all of the imports as well. And this is what some of the processors
> do. This incostistent behaviour is the first problem.
> 
> But ok, if applications always use only one <import> statement, that
> incostistency goes away.

Right, that's the sensible defensive strategy.

> Now, this obviously means that we are importing the namespace (with all of
> its definitions), not the definitions themselves. But then, why do we need
> two attributes there? Why schemaLocation? I mean if the namespace is always
> bound to only one schema location, that attribute is completelly redundand.

Sorry, how does it get bound to _any_ schema location?  Answer -- the
spec. provides a range of options for processor and/or user to
employ/specify, everything from "nothing, because I've got that one
built in" through "try derefing the NS name" to "use schemaLoc".

> The existence of that attribute and the fact that it is not required that
> anything actually exists at the end of the namespace URI produces the
> conclusion that <import> does not really import the namespace (with all of
> its definitions), but imports specific definitions from it.
> 
> Now which one is correct?

Neither.  The fundamental purpose of <xs:import namespace='nsName'> is
to allow references (e.g. ref=, base=) to names qualified by nsName.

> Even with this issue resolved, the fact that you cannot modularize the
> schemas is a real problem. Acheving scalability is affected. Building
> mutually dependant, "networked" or hierarchical schema sets from different
> domain and for different purposes is significantly affected. I mean this
> almost means that I have to have different namespace for each of my
> definitions.

There is a tradeoff here, but the common approach to this is to go
ahead and modularise, and use <xs:include> to manage the
modularisation (that's what _it_ is meant for).  In the case of
importing a modularly-defined schema, that does mean you have to
create a stub schema document which consists entirely of
<xs:include>s, which you then point to from the schemaLoc of your
import.

Hope this helps.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2002, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/
 [mail really from me _always_ has this .sig -- mail without it is forged spam]

Received on Monday, 4 November 2002 05:04:35 UTC