On 20 Jul 2009, at 17:42 , Costello, Roger L. wrote:

>
> Hi Folks,
>
> In XSD 1.1 a schema can have multiple targetNamespaces.

Not in general, no.  In some fairly tightly constrained
situations, it's possible to write declarations that
generate components in a namespace other than the
target namespace.  I won't attempt to reproduce all the
details of the conditions that must be met (but see below).

> Presumably this capability was introduced to solve a problem. What  
> problem is it solving?

User input has complained about a very specific
scenario.

Suppose you are defining a type R, which is intended to
be a restriction of type outside-organization:T, defined
by some outside organization in their namespace.

Suppose type T has a required (namespace-qualified) local
element outside-organization:LE.  You need a declaration
for outside-organization:LE in your definition of your:R,
because the rules for restriction say you have to
reproduce the entire content model.  But your target
namespace is not the outside organization's target
namespace.  What do you do?

In 1.0, the answer is:  you must define R in the
outside organization's namespace, by supplying your own
schema document for that namespace.  Otherwise, you lose.

The user input on the 1.1 rule for this scenario was
essentially:  that stinks.

So some members of the WG requested a change to make the
scenario (your:R restricting outside-organization:T and
reproducing its local elements, etc.) legal.

The simplest way to deal with this problem would have
been to say "Sorry, you lose."  I had a certain sympathy
for this approach, but it's possible that was because
they weren't my customers complaining.

The next simplest way around this problem would have been to
blast away all the thinking and design which has been built
into XSD about the relations among schema documents, schemas,
and namespaces.  That didn't seem the right thing for a 1.1
release.  Also, not everyone would be inclined to think that
destroying all of those aspects of the design would be a
good thing.

So in order to retain as much of the design principle as
possible, while still making the scenario legal, we wrote
a series of ad-hoc conditions into the rules that are
intended to make the kind of restriction described in the
scenario legal, but otherwise to leave the rules about
schema documents and namespaces alone.  They are the kind
of complicated rules some readers of the XSD spec have
come to love, checking the namespace of the base type
and the nature of the derivation, and adding special
clauses to deal with the case that outside-organization:T
is itself a restriction of third-party:X, and performing
(or requiring in the reader) all manner of mental
gymnastics.  Like Latin, it disciplines the mind, right?
I don't remember whether the rules still check the
phase of the moon and test whether the system clock is
currently showing a leap second or a prime number of minutes
since the birth of Alan Turing; possibly those were removed
during WG review (it's so easy to lose track of these
details).  But they uphold the sacred traditions of the
XSD spec and will do their bit to maintain its reputation
for refusing to compromise when it comes to clarity.

I hope this helps.



-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************