Re: What is the meaning of the import statement?

Mary,

thank you very much for the response. But I think that my problem is still
there.

The incosistency that bothers me is the following:

1. When it comes to importing the definitions, the processors are using the
schema location information. It may be the "default" schema location in the
schemaLocation attribute, or it may be the schema location information
provided externally, by the parser. I guess there might be other ways. But
it is the schema location information, not the namespace.

2. When it comes to deciding whether to import more definitions (at the
moment when parser encounters subsequent import statements), the decision is
made solely based on the namespace; the information about the schema
location is completelly ignored.

My objection is that the step 2 should be based on schema location as well
(and it could be the same way as in step 1, i.e. the schemaLocation is the
default, but processors may override it). That would mean that same
"physical" definition collections (schema files, URIs that resolve to
<schema> element, etc...) are not imported twice.

The other way around is to change the step 1 to be based on the same
information as step 2 (namespace) - this is less preferable.

Anyways, what happens is that if you import only a subset of schemas from a
namespace, you cannot import the rest anymore. And this is true even if you
place those imports in different files, like so:

schema A.xsd (namespace=abc)
    include subschema1.xsd
    include subschema2.xsd

subschema1.xsd
     import my namespace, schemaLocation=subset1.xsd

subschema2.xsd
     import my namespace, schemaLocation=subset2.xsd

subset2 will never be imported since the "my" namespace has already been
imported in subschema1.xsd, so every other import statement of the "my"
namespace is ignored. The specification actually says that the processor may
go either way, but at least one of the most popular processor is working
exactly in the way I've described.

Cheers

Milan



----- Original Message -----
From: "Mary Holstege" <holstege@mathling.com>
To: "Milan Trninic" <mtrninic@galdosinc.com>
Sent: Thursday, October 31, 2002 12:04 PM
Subject: Re: What is the meaning of the import statement?


>
> The schemaLocation is optional on import under the general operating
theory
> for binding schemas to namespaces that a schema processor may not wish to
> dereference a specific URI it found in a document, but may have a cache,
may
> have built-in schemas, or who knows what. import really says "I'm going to
> refer to definitions in this namespace" the schemaLocation is a hint just
as it
> is in the instance document.
>
> If you want to partitition a schema into a bunch of separate files, then
the
> modularity construct you're looking for is include, which has a location.
>
> There are a number of ways to manage this, but one pattern I use a lot is
> something like this:
>
> root schema for namespace A:
>     include fileA1 and fileA2, both of which are (partial) schemas for
>     namespace A
>
> root schema for namespace B:
>     includes fileB1 and fileB2, both of which are (partial) schemas for
>     namespace B
>
>
> application schema 1
>     import namespace A
>
> application schema 2
>     import namespace A
>     import namespace B
>
> and so on.
>
> Another way to manage this is to have the includes pushed up a level:
>
> schema 1
>     include A1
>
> schema 2
>     include A1
>     include A2
>
> schema 3
>     include A1
>     inlcude A3
>
> and so forth
>
> I find the latter approach is usually more appropriate when there is only
> really one namespace and the schemas 1 through 3 are for different logical
> subparts of the namespace. So, for example, A1 may have some base level
> definitions, A2 may have some that only apply in some cases, A3 some that
apply
> in others.
>
> //Mary
>
>

Received on Friday, 1 November 2002 03:22:58 UTC