W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2002

What is the meaning of the import statement?

From: Milan Trninic <mtrninic@galdosinc.com>
Date: Thu, 31 Oct 2002 10:27:19 -0800
Message-ID: <004501c2810b$25a6b1a0$690aa8c0@mtrninic>
To: <www-xml-schema-comments@w3.org>, <xmlschema-dev@w3.org>
Cc: "At Galdos" <mtrninic@galdosinc.com>

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.

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.

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?

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

And this lack of capability for modularization within one namespace is also
incosistent with the following excerpt ("...definitions ... piece by piece")
from the XMLSchema specification (which occured to me as an idea even before
I found it in the specification - which means that it is very natural idea).

XML Schema Part 1: Structures

"4.3.2 How schema definitions are located on the Web
Improved or alternative conventions for Web interoperability can be
standardized in the future without reopening this specification. For
example, the W3C is currently considering initiatives to standardize the
packaging of resources relating to particular documents and/or namespaces:
this would be an addition to the mechanisms described here for layer 3. This
architecture also facilitates innovation at layer 2: for example, it would
be possible in the future to define an additional standard for the
representation of schema components which allowed e.g. type definitions to
be specified piece by piece, rather than all at once"

Actually I sincerelly hope I am missing something here.


Milan Trninic
Senior Software Engineer
Galdos Systems Inc.
Received on Thursday, 31 October 2002 13:27:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:59 UTC