What does elementFormDefault do in XSD?

Question

What does elementFormDefault do, and when should it be used?

So I found some definitions for elementFormDefault values:

qualified - elements and attributes are in the targetNamespace of the schema

unqualified - elements and attributes do not have a namespace

So from that definition I would think that if a schema is set to qualified then why must you prefix the type with the namespace? And what are the scenarios that you would even have one set to unqualified for that matter? I tried Googling, but all I got were a couple W3C pages that were extremely hard to understand.

This is the file I am working with right now, why do I need to declare the type as target:TypeAssignments when I declare the targetNamespace as the same one as xmlns:target?

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:target="http://www.levijackson.net/web340/ns"
        targetNamespace="http://www.levijackson.net/web340/ns" 
        elementFormDefault="qualified">
  <element name="assignments">
    <complexType>
      <sequence>
        <element name="assignments" type="target:TypeAssignments"
                 minOccurs="1" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <complexType name="TypeAssignments">
    <sequence>
      <element name="assignment" type="target:assignmentInfo"
               minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
  </complexType>
  <complexType name="assignmentInfo">
    <sequence>
      <element name="name" type="string"/>
      <element name="page" type="target:TypePage"/>
      <element name="file" type="target:TypeFile" 
               minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="id" type="string" use="required"/>
  </complexType>
  <simpleType name="TypePage">
    <restriction base="integer">
      <minInclusive value="50" />
      <maxInclusive value="498" />
    </restriction>
  </simpleType>
  <simpleType name="TypeFile">
    <restriction base="string">
      <enumeration value=".xml" />
      <enumeration value=".dtd" />
      <enumeration value=".xsd" />
    </restriction>
  </simpleType>
</schema>

Conlin

Answer 1

ElementFormDefault has nothing to do with namespace of the types in the schema, it's about the namespaces of the elements in XML documents which comply with the schema.

Here's the relevent section of the spec:

Element Declaration Schema

Component Property  {target namespace}
Representation      If form is present and its ·actual value· is qualified, 
                    or if form is absent and the ·actual value· of 
                    elementFormDefault on the <schema> ancestor is qualified, 
                    then the ·actual value· of the targetNamespace [attribute]
                    of the parent <schema> element information item, or 
                    ·absent· if there is none, otherwise ·absent·.

What that means is that the targetNamespace you've declared at the top of the schema only applies to elements in the schema compliant XML document if either elementFormDefault is "qualified" or the element is declared explicitly in the schema as having form="qualified".

For example: If elementFormDefault is unqualified -

<element name="name" type="string" form="qualified"></element>
<element name="page" type="target:TypePage"></element>

will expect "name" elements to be in the targetNamespace and "page" elements to be in the null namespace.

To save you having to put form="qualified" on every element declaration, stating elementFormDefault="qualified" means that the targetNamespace applies to each element unless overridden by putting form="unqualified" on the element declaration.

Beaty

Although this answer refers to the spec it doesn't interpret it correctly. Locally defined elements are still in the targetNamespace and are never in the null namespace. elementFormDefault is just a switch which specifies whether or not you are supposed to namespace qualify them in an instance. – Blatherskite

@Ihe, that's not correct: or at any rate, it's liable to confuse people. If a local element declaration does not have form=qualified, then the {target namespace} property of the element declaration schema component is "absent", and that means the namespace URI property of the element instance must also be "absent. – Mutz

@MichaelKay To me that is even more confusing. The question is whether in the example page is in the null namespace, because if it is why doesn't the spec simply say setting elementFormDefault = unqualified puts locally defined elements in the null namespace. Is saying that page shouldn't be namespace qualified in an instance the same thing as saying page is in no namespace cos if it is why doesn't the spec simply say that and why is a schema with a targetNamespace validating things that aren't in that namespace? – Blatherskite

Also @MichaelKay how do you distinguish an unqualified page element from a different XML vocabulary appearing in the same document if they are both in the null or no namespace. – Blatherskite

It doesn't "simply say that" because you're describing it very informally: the phrase "putting an element in the null namespace" isn't using the terminology of the XSD specification; the spec prefers to use much more careful terminology, which often makes it hard to read but ends up being a lot more precise. – Mutz

@MichaelKay The answer we are commenting on says "will expect "name" elements to be in the targetNamespace and "page" elements to be in the null namespace". So the informal description you are referring to originates from the answer not my comment and that is what my comment takes issue with. – Blatherskite

As far as I'm concerned, it's a correct answer as written. – Mutz

I don't understand what you explained. But it's ok. – Blatherskite

Answer 2

_{New, detailed answer and explanation to an old, frequently asked question...}

Short answer: If you don't add elementFormDefault="qualified" to xsd:schema, then the default unqualified value means that locally declared elements are in no namespace.

There's a lot of confusion regarding what elementFormDefault does, but this can be quickly clarified with a short example...

Streamlined version of your XSD:

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:target="http://www.levijackson.net/web340/ns"
        targetNamespace="http://www.levijackson.net/web340/ns">
  <element name="assignments">
    <complexType>
      <sequence>
        <element name="assignment" type="target:assignmentInfo" 
                 minOccurs="1" maxOccurs="unbounded"/>
      </sequence>
    </complexType>
  </element>
  <complexType name="assignmentInfo">
    <sequence>
      <element name="name" type="string"/>
    </sequence>
    <attribute name="id" type="string" use="required"/>
  </complexType>
</schema>

Key points:

• The assignment element is locally defined.
• Elements locally defined in XSD are in no namespace by default.
  • This is because the default value for elementFormDefault is unqualified.
  • This arguably is a design mistake by the creators of XSD.
  • Standard practice is to always use elementFormDefault="qualified" so that assignment is in the target namespace as one would expect.
• It is a rarely used form attribute on xs:element declarations for which elementFormDefault establishes default values.

Seemingly Valid XML

This XML looks like it should be valid according to the above XSD:

<assignments xmlns="http://www.levijackson.net/web340/ns"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.levijackson.net/web340/ns try.xsd">
  <assignment id="a1">
    <name>John</name>
  </assignment>
</assignments>

Notice:

• The default namespace on assignments places assignments and all of its descendents in the default namespace (http://www.levijackson.net/web340/ns).

Perplexing Validation Error

Despite looking valid, the above XML yields the following confusing validation error:

[Error] try.xml:4:23: cvc-complex-type.2.4.a: Invalid content was found starting with element 'assignment'. One of '{assignment}' is expected.

Notes:

• You would not be the first developer to curse this diagnostic that seems to say that the content is invalid because it expected to find an assignment element but it actually found an assignment element. (WTF)
• What this really means: The { and } around assignment means that validation was expecting assignment in no namespace here. Unfortunately, when it says that it found an assignment element, it doesn't mention that it found it in a default namespace which differs from no namespace.

Solution

• Vast majority of the time: Add elementFormDefault="qualified" to the xsd:schema element of the XSD. This means valid XML must place elements in the target namespace when locally declared in the XSD; otherwise, valid XML must place locally declared elements in no namespace.
• Tiny minority of the time: Change the XML to comply with the XSD's requirement that assignment be in no namespace. This can be achieved, for example, by adding xmlns="" to the assignment element.

---

_{Credits: Thanks to Michael Kay for helpful feedback on this answer.}

Odonnell

"The { and } around [the element]"... Ah! THIS is what clued me in to the solution to what I've been struggling with for an hour, now! Thanks! – Honegger

Answer 3

Consider the following ComplexType AuthorType used by author element

<xsd:complexType name="AuthorType">
  <!-- compositor goes here -->
  <xsd:sequence>
     <xsd:element name="name" type="xsd:string"/>
     <xsd:element name="phone" type="tns:Phone"/>
  </xsd:sequence>
  <xsd:attribute name="id" type="tns:AuthorId"/>
</xsd:complexType>
<xsd:element name="author" type="tns:AuthorType"/>

If elementFormDefault="unqualified"

then following XML Instance is valid

<x:author xmlns:x="http://example.org/publishing">
   <name>Aaron Skonnard</name>
   <phone>[phone]</phone>
</x:author>

the authors's name attribute is allowed without specifying the namespace(unqualified). Any elements which are a part of <xsd:complexType> are considered as local to complexType.

if elementFormDefault="qualified"

then the instance should have the local elements qualified

<x:author xmlns:x="http://example.org/publishing">
   <x:name>Aaron Skonnard</name>
   <x:phone>[phone]</phone>
</x:author>

please refer this link for more details

Latini

Umm...name is an element, not an attribute. – Burrton

Answer 4

Important to note with elementFormDefault is that it applies to locally defined elements, typically named elements inside a complexType block, as opposed to global elements defined on the top-level of the schema. With elementFormDefault="qualified" you can address local elements in the schema from within the xml document using the schema's target namespace as the document's default namespace.

In practice, use elementFormDefault="qualified" to be able to declare elements in nested blocks, otherwise you'll have to declare all elements on the top level and refer to them in the schema in nested elements using the ref attribute, resulting in a much less compact schema.

This bit in the XML Schema Primer talks about it: http://www.w3.org/TR/xmlschema-0/#NS

Friseur

Slight clarification on what looks like the most accurate answer. With elementFormDefault=qualified you must namespace qualify local elements in the intance. With it set to unqualified you must not namespace qualify them. – Blatherskite

Answer 5

elementFormDefault="qualified" is used to control the usage of namespaces in XML instance documents (.xml file), rather than namespaces in the schema document itself (.xsd file).

By specifying elementFormDefault="qualified" we enforce namespace declaration to be used in documents validated with this schema.

It is common practice to specify this value to declare that the elements should be qualified rather than unqualified. However, since attributeFormDefault="unqualified" is the default value, it doesn't need to be specified in the schema document, if one does not want to qualify the namespaces.

Crossquestion

elementFormDefault only applies to locally defined elements. Global elements must be namespaced qualified regardless. – Blatherskite

Answer 6

I have noticed that XMLSpy(at least 2011 version)needs a targetNameSpace defined if elementFormDefault="qualified" is used. Otherwise won't validate. And also won't generate xmls with namespace prefixes

Defrost