Michael Kay writes:

> I forget how chameleon namespaces interact with
> elementFormDefault - it's a facility I never use, so I would
> have to look it up.

OK, so I was feeling guilty about not remembering either, so I looked it
up.  From [1] (in which SII' is the schema document doing the including):

3.2 If clause 2.3 above is satisfied [I.e. if the targetNamespace of the
included schema document is missing...Noah]   , then the schema
corresponding to the <include>d item's parent <schema> must include not
only definitions or declarations corresponding to the appropriate members
of its own [children], but also components identical to all the ·schema
components· of I, except that anywhere the ·absent· target namespace name
would have appeared, the ·actual value· of the targetNamespace [attribute]
of SII' is used. In particular, it replaces ·absent· in the following
places:
3.2.1 The {target namespace} of named schema components, both at the top
level and (in the case of nested type definitions and nested attribute and
element declarations whose code was qualified) nested within definitions;
3.2.2 The {namespace constraint} of a wildcard, whether negated or not;

In case that for some reason that seems unclear, I'll translate:  you can
mostly assume that the included schema document behaves as if it did have
a targetNamespace corresponding to that of the including schema document.
Specifically, this is true for "nested attribute and element declarations
that have as their code "qualififed", which are the ones in question.  If
your elementForm is qualified, then the namespace used will be that of the
including schema document.  That's my reading anyway.

Noah

[1] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#compound-schema

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------