What does targetNamespace do ? Am I getting it right?

Question

Here is the <schema> tag of my XSD:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="http://www.cmu.edu/ns/blank"
    targetNamespace="http://www.cmu.edu/ns/blank"
    elementFormDefault="qualified">

If my understanding is correct, here is what it means:

This schema itself belongs to http://www.w3.org/2001/XMLSchema namespace

The root of the XML instance should belong to http://www.cmu.edu/ns/blank namespace

All the elements within the XML instance which do not have a prefix automatically belong to http://www.cmu.edu/ns/blank namespace as elementFormDefault is qualified

Question1: Is my understanding correct. If not, what is wrong ?

Question2 Look at the undermentioned XML instance:

<people
xmlns="http://www.cmu.edu/ns/blank"
xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.cmu.edu/ns/blank student.xsd"
>
    <student>
        <name>John</name>
        <course>Computer Technology</course>
        <semester>6</semester>
        <scheme>E</scheme>
    </student>
</people>

Here everything belongs to http://www.cmu.edu/ns/blank namespace including <student> and the elements contained within because of elementFormDefault. Correct?

Question3
Now, I want to add <student> from various Universities. with prefixes like berk for Berkley, harv for Harvard, etc. Each <student> has a different set of elements within. And I want to validate that. How is that possible?

Q3 does not sound like an appropriate use for XML namespaces. This would be like defining a `BerkStudent` class and a `HarvStudent` class in a programming language type system. — McDowell, May 10 '13 at 12:46
@McDowell Yes, you are right however I could use `` in the XSD for Berkley and Harvard and add more fields. That would be like generalization/specialization relation :) — An SO User, May 10 '13 at 12:59
You're thinking about it backwards - the schema doesn't "automatically cause" anything in the instance document, it's up to you to use the right combination of default namespaces and prefix declarations in the instance document to make it match what the schema expects. The `elementFormDefault` is one of the things that affects these _expectations_. — Ian Roberts, May 10 '13 at 18:22
@IanRoberts Since the root of the schema-instance belongs to certain namespace, all the child elements will also belong to that namespace (inherited that is) unless stated otherwise ? — An SO User, May 10 '13 at 21:25
@LittleChild it's the normal XML rules, regardless of whether or not there's a schema involved. For `` the student element is in the `example` namespace, but for `` it isn't. — Ian Roberts, May 11 '13 at 08:22

score 6 · Accepted Answer · answered May 11 '13 at 03:09

(1) The first two points are OK; the third one:

All the elements within the XML instance which do not have a prefix automatically belong to http://www.cmu.edu/ns/blank namespace as elementFormDefault is qualified

is incorrect.

Declaring a prefix in the schema doesn't mean that the XML instance must use the same prefixes. Any namespace declaration in the XSD file, applies only to the XML file that is XSD (XSD is an XML, therefore...)

In general, there is no way to assume anything about any prefixed or un-prefixed element name; i.e. below examples are all correct.

<some xmlns="" .../>
<some xmlns="urn:tempuri-org:XSD:1" .../>
<x:some xmlns:x="urn:tempuri-org:XSD:1" .../>

The only sure thing is that the only way to represent an unqualified name is through a name without a prefix (i.e. one cannot prefix the "empty" namespace).

elementFormDefault controls the form of the element's name, when an element is declared within a content model (i.e. is not global).

(2) Partially correct. The part because of elementFormDefault. is incorrect. Again, XSD is just one schema spec; XML exists and has its own rules, irrespective of XSD, or any other schema language. The rule that applies here is that of XML namespaces, specifically scoping.

(3) You would have to create an XSD for each namespace; within each namespace, you declare the student and it's content. Then the XSD which defines people would import the other XSDs and reference students appropriately.

So this is a basic setup:

Berkeley.xsd

<?xml version="1.0" encoding="utf-8" ?>
<!-- XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com) -->
<xsd:schema targetNamespace="urn:berkeley-org" xmlns="urn:berkeley-org" elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:element name="student"/>   
</xsd:schema>

Harvard.xsd

<?xml version="1.0" encoding="utf-8" ?>
<!-- XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com) -->
<xsd:schema targetNamespace="urn:harvard-org" xmlns="urn:harvard-org" elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:element name="student"/>   
</xsd:schema>

people.xsd

<?xml version="1.0" encoding="utf-8" ?>
<!-- XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com) -->
<xsd:schema targetNamespace="urn:people-org" xmlns="urn:people-org" xmlns:harv="urn:harvard-org" xmlns:berk="urn:berkeley-org" elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:import namespace="urn:harvard-org"  schemaLocation="harvard.xsd"/>
    <xsd:import namespace="urn:berkeley-org" schemaLocation="berkeley.xsd"/>

    <xsd:element name="people">
        <xsd:complexType>
            <xsd:choice maxOccurs="unbounded">
                <xsd:element ref="harv:student"/>
                <xsd:element ref="berk:student"/>               
            </xsd:choice>
        </xsd:complexType>
    </xsd:element>
</xsd:schema>

The files graph:

enter image description here

A sample XML (shows the use of namespaces):

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!-- Sample XML generated by QTAssistant (http://www.paschidev.com) -->
<people xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:harv="urn:harvard-org" xmlns:berk="urn:berkeley-org" xmlns="urn:people-org">
    <harv:student/>
    <berk:student/>
</people>

enter image description here

I read a bit more on `elementFormDefault` here: http://www.levijackson.net/elementformqualified-what-is-it/ and that solved the myth for me. To sum it up : `elementFormDefault="qualified"` -- all the elements belong to targetNameSpace. If *unqualified* they belong nowhere, unless a "blank" namespace has been declared. The inference is from the website — An SO User, May 11 '13 at 07:05
@LittleChild there's no "unless" - xmlns declarations don't come into it. With `elementFormDefault="qualified"` local elements declared inside a complexType go into the targetNamespace of the schema, with unqualified they are in no namespace (i.e. only global top level element declarations take on the target namespace). — Ian Roberts, May 13 '13 at 22:53
@LittleChild / @IanRoberts: strictly speaking, the key thing to remember here is "default", i.e. elementForm `Default` provides a default (initializer) when the `form` attribute is not used. In other words, no matter what the default says, the form attribute takes precedence. So, even here, there is an `unless`: i.e. `With elementFormDefault="qualified" local elements declared inside a complexType go into the targetNamespace of the schema,` UNLESS the form attribute says otherwise. — Petru Gardea, May 13 '13 at 23:18

score 2 · Answer 2 · edited May 23 '17 at 11:58

Petru's answer is a good one, but it requires that the base "people" schema be aware of (and import) all the different college-specific schemas - if you want to add a new college you have to update the base schema to match. A different approach would be to reverse the direction of the imports by having the base schema declare a base "student" type, possibly with elements that are common to all colleges, which the other schemas extend using the substitution group mechanism.

people.xsd

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="urn:people"
    xmlns:p="urn:people"
    elementFormDefault="unqualified">

  <xs:element name="people">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="p:student" minOccurs="0" maxOccurs="unbounded" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:complexType name="studentType">
    <xs:sequence>
      <xs:element name="name" type="xs:string" />
    </xs:sequence>
  </xs:complexType>

  <xs:element name="student" type="p:studentType" />
</xs:schema>

harvard.xsd

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="urn:harvard"
    xmlns:p="urn:people"
    elementFormDefault="unqualified">
  <xs:import namespace="urn:people"  schemaLocation="people.xsd"/>

  <xs:element name="student" substitutionGroup="p:student">
    <xs:complexType>
      <xs:extension base="p:studentType">
        <xs:element name="harvardId" type="xs:string" />
      </xs:extension>
    </xs:complexType>
  </xs:element>
</xs:schema>

berkeley.xsd

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="urn:berkeley"
    xmlns:p="urn:people"
    elementFormDefault="unqualified">
  <xs:import namespace="urn:people"  schemaLocation="people.xsd"/>

  <xs:element name="student" substitutionGroup="p:student">
    <xs:complexType>
      <xs:extension base="p:studentType">
        <xs:element name="berkeleyId" type="xs:string" />
      </xs:extension>
    </xs:complexType>
  </xs:element>
</xs:schema>

Instance document

<p:people xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:harv="urn:harvard" xmlns:berk="urn:berkeley" xmlns:p="urn:people"
          xsi:schemaLocation="urn:people people.xsd urn:harvard harvard.xsd
                              urn:berkeley berkely.xsd>
  <harv:student>
    <name>John</name>
    <harvardId>12345</harvardId>
  </harv:student>
  <berk:student>
    <name>Mary</name>
    <berkeleyId>ABCDE</berkeleyId>
  </berk:student>
</p:people>

Note that I've used elementFormDefault="unqualified" in this example to simplify the namespaces in the instance documents. If I'd used qualified then you'd have to say something like

<harv:student>
  <p:name>John</p:name>
  <harv:harvardId>12345</harv:harvardId>
</harv:student>

(i.e. the elements under harv:student that were inherited from the base p:studentType would have to be in the urn:people namespace but those declared in the harvard.xsd extension would have to be in the urn:harvard namespace).

The key points to understand here are:

the people schema declares a global complex type studentType and a global element student of this type, and declares the people element as a sequence of {urn:people}student.
each college-specific schema declares its own element with substitutionGroup="p:student" and with a type that extends p:studentType. This tells the validator that anywhere where a {urn:people}student is expected, a {urn:college}student is also acceptable.
when you want to add a new college, you just create a similar schema with a new element in the same substitutionGroup and you can refer to that in instance documents - there's no need to change the people schema.

Good one, too; the reason why I didn't mentioned here but I put it in many other answers, e.g. [here](http://stackoverflow.com/questions/9008622/how-to-extend-a-choice-complextype-without-sequencing-the-choice/9008966#9008966) is that substitution groups is a much more advanced concept to handle for a beginner, plus it is not widely and/or equally supported in various implementations. So if I may suggest, now that you've started it: max interop is achieved if the head of the substitution group is marked as abstract; you don't need to define a base type for student... — Petru Gardea, May 13 '13 at 23:06
(cont'd) ... unless you want a common abstraction; and the best practice is to separate the definition of the reusable components (student and its type) from the use of it (here people). So the ultimate setup (what I would call production level) is to have a people schema referencing a student schema which is then referenced by the other two. — Petru Gardea, May 13 '13 at 23:07

What does targetNamespace do ? Am I getting it right?

2 Answers2

Linked