RE: target namespace and namespaces

I think you have things about right.  Method 2 is legal but troublesome.
The Schema WG hopes to improve versioning issues and composition 
in general in a future version of the specification.

As you mention, schemaLocation is only a hint for import, so it's
not safe to depend on it across different processors.

<import>ing a namespace that is the same as the target namespace of
the importing schema document will probably fail or do nothing.  
The processors already "knows" about that namespace, so it can ignore
the <import>. 

There is a error in your statement about <include>. The included
document *can* have a target namespace if the namespace
is the same as the target namespace of the including document.

xan

-----Original Message-----
From: Dan Vint
Subject: target namespace and namespaces

Can someone help with a better understanding of the relationship of a 
target namespace, the namespace and a schema composed of multiple files?

Let me build an example:

1) I create a schema (all in one file) and assign a namespace and 
targetNamespace. A data stream that references this namespace gets the 
entire schema and alls it definitions. To me 1 namespace = 1 schema and in 
this case there is no option to break it up.

2) Now take the same schema and break it up into separate files. I have one 
file with common stuff and two other files that include this common file, 
but each adds different containing elements. Both of these files have the 
same namespace associated with them. Now I have 1 namespace = 2 different 
schemas. A data stream that validates against schema 1 with namespace=foo 
will not validate against schema 2 with namespace=foo. A substantial amount 
may be legal because of the shared common information but the upper wrapper 
elements would immediately fail validation.

Is there anything that considers method 2 a legal design?

If it isn't illegal is it at least a really poor and troublesome design?