XSD targetNamespace does not override element namespace?

Question

I have an XSD that defines an complex type and has the targetNamespace attribute set. Is it correct that the TestElement will not gain the namespace set by targetNamespace? It should gain the namespace from the complex type afn:ElementType and therefore http://anotherfancy.namespace, right?

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:sfn="http://somefancy.namespace"
            xmlns:afn="http://anotherfancy.namespace"
            attributeFormDefault="unqualified"
            elementFormDefault="qualified"
            targetNamespace="http://somefancy.namespace"
            version="1.0">
      <xs:import namespace="http://anotherfancy.namespace" schemaLocation="..."/>
      <xs:element name="MyComplexType">
         <xs:complexType>
            <xs:sequence>
               <xs:element minOccurs="0" name="TestElement" type="afn:ElementType">
               </xs:element>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
   </xs:schema>

kjhughes · Accepted Answer · 2019-03-28T13:49:20.597

When `xs:schema/elementFormDefault="qualified"`

^{(As in your case, which is also the recommended and most commonly used setting of elementFormDefault.)}

The elements declared within an XSD must be in the namespace given by the XSD's targetNamespace.

Therefore, for your XSD, TestElement will have to be in the http://somefancy.namespace for the XML document to be valid. If you instead want it to be in the http://anotherfancy.namespace, declare the element in the imported XSD; storing its type there will not place the element itself in that other namespace. Once TestElement is declared in the imported namespace, it can be used in the original namespace via xs:element/@ref.

See also How to reference element in other XSD's namespace?

For rarely needed, and generally not recommended, other variations

See Michael Kay's answer here and my longer answer to this question: What does elementFormDefault do in XSD?

This isn't the full story; it ignores the difference between local and global element declarations, and the impact of `form` and `elementFormDefault`. — Michael Kay, Mar 28 '19 at 13:19
@MichaelKay: True, I should have elaborated, or at least mentioned, `elementFormDefault` et al considerations. Answer updated. Thank you. — kjhughes, Mar 28 '19 at 13:41

score 1 · Answer 2 · answered Mar 28 '19 at 13:17

The namespace of an element declared in a local element declaration is given in the following rule (XSD 1.1 part 1 §3.3.2.3)

{target namespace}

The appropriate case among the following:
1 If targetNamespace is present [as an attribute of the xs:element element], then its ·actual value·.
2 If targetNamespace is not present and one of the following is true
2.1 form = qualified
2.2 form is absent and the <schema> ancestor has elementFormDefault = qualified
then the ·actual value· of the targetNamespace [attribute] of the ancestor <schema> element information item, or ·absent· if there is none.
3 otherwise ·absent·.

The targetNamespace attribute of xs:element is new in 1.1, so for 1.0 you can ignore rule 1.

The form attribute of xs:element is very rarely used, but if the value is qualified then the element goes in the targetNamespace declared on the containing xs:schema, while if it is unqualified then it goes in no namespace. If form is not specified (which is nearly always the case), then it defaults to the value of elementFormDefault on the xs:schema element. This is usually set to qualified, so the element goes in the target namespace of the schema; but the default (unfortunately) is unqualified which means it goes in no namespace.

XSD targetNamespace does not override element namespace?

2 Answers2

When xs:schema/elementFormDefault="qualified"

For rarely needed, and generally not recommended, other variations

When `xs:schema/elementFormDefault="qualified"`