W3C home > Mailing lists > Public > xmlschema-dev@w3.org > December 2004

Re: target namespace and namespaces

From: W. Eliot Kimber <ekimber@innodata-isogen.com>
Date: Fri, 03 Dec 2004 11:12:22 -0600
Message-ID: <41B09E76.3070306@innodata-isogen.com>
To: Michael Kay <mike@saxonica.com>
CC: "'Dan Vint'" <dvint@dvint.com>, xmlschema-dev@w3.org

Michael Kay wrote:

> On the other hand, XML Schema suggests that knowing the target namespace is
> enough information for a schema processor to go and find a schema, with the
> schema location being just a hint. If there is more than one schema for a
> namespace, then there is no way of telling the processor reliably which one
> you want to use.

I do think that only top-level XSD schema documents should be bound to 
namespaces. That is, it is important to be able to tell whether a given 
XSD document is the root of a complete schema for the namespace or 
simply a component of a larger schema. Putting namespaces on XSD 
documents that are only modules definitely confuses things.

That is, in my XIRUSS-T repository, when I import an XSD document the 
importer really needs to be able to distinguish top-level XSD documents 
from XSD module documents.

For example, if I import a document that uses a given namespace and 
there are multiple XSD documents associated with that namespace, I would 
need to present a list of schemas to the user from which they would 
select the one or ones to associate. You would only want top-level XSD 
schema documents in that list.

This is complicated by the fact that a given (abstract) document type 
might be composed from several namespaces, some of which are intended to 
govern entire documents, some of which are only partial modules.

Hmmm. The issue I'm seeing here is what is the best way to define and 
use document type "modules" that define only types that are only 
meaningful in the context of a larger, "encompassing", schema?

I think the answer might be that such modules should only define types 
and no global elements.

But I think more experimentation is required.


W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122

Received on Friday, 3 December 2004 17:12:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:07 UTC