Why do we need targetNamespace?

Question

I would like to understand the purpose of targetNamespace, which is used both in the XML schema and in the WSDL. In fact, to keep things simple, let me restrict this question to an XML schema.

It seems to me that I fully understand the concept of (simple) XML namespaces. By convention, we use a URI / URL, but we can use any string that we then assign a prefix for reuse by XML nodes and attributes, or simply use the default namespace for the scope. So far, so good?

Now an XML schema is introduced. For some reason, the inventors of XML Schema believed that the concept of simple namespaces was not enough, and they needed to enter targetNamespace. My question is: what is the significant advantage of the targetNamespace representation, which cannot be provided by the usual XML namespace? If the XML document refers to the xsd document, either using schemaLocation or using the import statement, in any case, I give the path to the actual xsd document referenced. This is what uniquely identifies the scheme I want to reference. If, in addition, I want to bind this schema to a specific namespace in my reference document, why should I be obligated to replicate the exact target namespace already defined in the XML schema that I reference? Why can't I just override this namespace, but I want the XML document in which this namespace will be used to reference this particular XML schema document that I want to reference?

Update:

To give an example, if the XML instance document has the following:

<p:Person xmlns:p="http://contoso.com/People" xmlns:v="http://contoso.com/Vehicles" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://contoso.com/schemas/Vehicles http://contoso.com/schemas/vehicles.xsd http://contoso.com/schemas/People http://contoso.com/schemas/people.xsd"> <name>John</name> <age>28</age> <height>59</height> <v:Vehicle> <color>Red</color> <wheels>4</wheels> <seats>2</seats> </v:Vehicle> </p:Person> 

Why, for example, does the people.xsd schema need to define a target namespace that is "http://contoso.com/schemas/People"? Why do we even need to define targetNamespace in an xsd document? It seems to me that everything you need to get from part of the schema namespace is already contained in the XML instance document. What is the advantage of having targetNamespace with equal value in an xsd document?

The next question for Paul:

Can you give me a concrete example where such “collisions” between xsd element names become apparent, and this explains the need for targetNamespace?

---

Ok, here is an attempt to answer my own question. Let me know if this seems consistent to you. Looking at the examples on the page related to Paul helped me.

If we take the XML instance example in the original question above, we have two links to the vehicle element definition. One of them is explicit and visible in the XML instance document itself, but we must also imagine that the person.xsd XML schema refers to the same vehicle definition as the permitted child of the person. If we used regular namespaces, where each document was allowed to define its own namespace for the vehicle, how do we know that the XML instance refers to the same XML schema definition for the vehicle as man.xsd? The only way is to use the concept of a namespace, which is more strict than the original simple one, and which should be written in the same way in several documents.

If I hadn’t written this on a tablet, I would have provided an example code, but here I’ll just try to describe the example that I have in mind.

Imagine that we have two different XML schema definitions for a vehicle element. location1 / vehicles.xsd will contain a definition that confirms an example from the question about this message (containing the color, wheels and elements of a child element), while location2 / vehicles.xsd will contain a completely different definition for a vehicle element (for example, with children , model and volume). Now, if the XML instance document refers to the location1 schema, as in the example above, but person.xsd says that the person element can contain a child of a vehicle of the type defined in Location2, and then without the concept of targetNamespace, the XML instance will check, even if he clearly does not have a suitable type of vehicle as a child of his personal element.

Then the namespace will help us make sure that if two different documents refer to the same third XML schema, they both are in fact referring to the same schema, not just a schema containing elements that are similar but not identical to another ...

Does that make sense?

Answer 1

You seem to be on the right track. I will make a few points here that may help.

• In an instance document, you use XML namespaces to identify the namespace in which the element or attribute resides.
• In the schema document, you declare the elements and attributes that will be displayed in the instances. What namespace are listed in them? To do this, use targetNamespace.
• The layout of the schema document and the namespace are not the same thing. Typically, there are multiple .xsd documents with the same target namespace. (They may or may not include each other, but will usually include each other.)
• Instance documents do not always have an xsi: schemaLocation element to tell parsers where to look for schemas. Various methods can be used to tell the parser where to find the appropriate schema documents. XSD can be hosted on a local drive or on some web address, and this should not affect the namespace of elements in it.
  • xsi: schemaLocation is a hint. Parsers can find the schema for a given namespace elsewhere, which implies that they should be able to know which namespace the schema is used for.
  • Tools, such as data binding tools, precompile schemas and produce code that recognizes valid documents. They should be able to know the namespaces of declared elements.

I think you assumed that the instance document could indicate the namespace of the elements and attributes declared in some schema document using xsi: schemaLocation. This does not work. First, the parser can find other documents in the schema than those listed, and must know for what namespace they are intended. On the other hand, this would make it difficult or difficult to reason about schemas: you could not look at the schema and know the namespaces in which everything belonged, because this decision will be delayed until an instance is written.

Answer 2

Q: "By convention, we use URI / URLs, but we can use any string that we then assign a prefix for reuse by XML nodes and attributes, or simply use the default namespace for the scope."

A: Yes, exactly.

Q: "For some reason, the inventors of the XML schema felt the concept of simple namespaces was not enough, and they had to imagine the target space."

A: http://www.liquid-technologies.com/Tutorials/XmlSchemas/XsdTutorial_04.aspx

Breaking schemas in multiple files can have several advantages. You can create reusable definitions that can be used in several projects. They make reading and versioning of the definitions easier since they break the circuit down into smaller units that are easier to manage.

...

All this works fine without namespaces, but if different teams start working on different files, then you have the possibility of name collisions, and this would not always be obvious when the definition comes from. The solution is to put the definitions for each file schema in a separate namespace.

Clarification:

• The main purpose of XML Schemas is to declare dictionaries.

• These dictionaries can be identified by the namespace specified in the targetNamespace attribute.

• A schema (XML document) may have a "namespace". A “dictionary” that describes a document may have “targetNamespace”.

• Just as XML schemas provide a higher level of abstraction than SGML DTDs (the original XML-DTD architects were sufficient), the targetNamespaces XML schema provides a level of abstraction over “simple namespaces”.

'Hope that helps

Answer 3

I think it helps to consider both an instance document and a schema document at the same time in order to understand what targetNamespace is. Consider this (based on your instance of the document):

 <p:Person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://localhost:8080/scribble/xml/Person" xmlns:v="http://localhost:8080/scribble/xml/Vehicle" xsi:schemaLocation=" http://localhost:8080/scribble/xml/Person http://localhost:8080/scribble/xml/person.xsd"> <name>John</name> <age>28</age> <height>59</height> <v:Vehicle> <color>Red</color> <wheels>4</wheels> <seats>2</seats> </v:Vehicle> </p:Person> 

There is no default namespace specified for the document, but p: * and v: * are aliases for specific NS URIs. Now take a look at the schema document itself:

 <?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://localhost:8080/scribble/xml/Person" elementFormDefault="qualified" xmlns:v="http://localhost:8080/scribble/xml/Vehicle"> <import namespace="http://localhost:8080/scribble/xml/Vehicle" schemaLocation="http://localhost:8080/scribble/xml/v.xsd"/> <element name="Person"> <complexType> <sequence> <element name="name" form="unqualified" type="NCName"/> <element name="age" form="unqualified" type="integer"/> <element name="height" form="unqualified" type="integer"/> <element ref="v:Vehicle"/> </sequence> </complexType> </element> </schema> 

and

 <?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://localhost:8080/scribble/xml/Vehicle" elementFormDefault="qualified"> <element name="Vehicle"> <complexType> <sequence> <element name="color" form="unqualified" type="NCName"/> <element name="wheels" form="unqualified" type="integer"/> <element name="seats" form="unqualified" type="integer"/> </sequence> </complexType> </element> </schema> 

If you look at the attributes in the tags, the default namespace is “ http://www.w3.org/2001/XMLSchema ” for both schema documents ... but targetNamespace is the name that is used as the namespace with an alias in the instance document .

targetNamespace is the expected instance namespace, regardless of the namespace of the schema documents and any other namespace specified in the instance document.

It seems to me that it is useful to think about this, for example, about having a party where you have a list of guests and guests wearing name tags. Think of targetNamespace in schema documents, such as names in a guest list. Xmlns, aliased or not, in instance documents look like name tags for guests. As long as you have a guest list (which miraculously includes a photocopy of an identity card issued by the state), whenever you encounter someone, you can verify your identity. If you come across someone wearing a name tag that does not match the specified parameters, you may run out of breath (i.e. throw an error).

With the schema / instances you have:

Schemas:

 targetNamespace="http://localhost:8080/scribble/xml/Person" targetNamespace="http://localhost:8080/scribble/xml/Vehicle" 

Instance:

 xmlns:p="http://localhost:8080/scribble/xml/Person" xmlns:v="http://localhost:8080/scribble/xml/Vehicle" 

Or ... any guest nicknamed "v" whom you come across anywhere in the party (forbid special rules that say otherwise), any floor of the house or in the backyard or in the pool, better matches the description for the guest in the guest list with named http: // localhost: 8080 / scribble / xml / Vehicle . or they are violators.

These special rules may say something like: V can only hang out if they are right next to P, or P can only hang out if V is present. In this case, P should freeze when V is, but V can go almost wherever they want without being there.

Thus, a schema can be incredibly flexible, defining virtually any data structure required and able to track what is happening by simply matching the namespaces (default or prefix) of any given element back to TNS and its associated schema.

Answer 4

It’s not clear to me exactly what you are asking. Obviously, a schema can contain definitions of components in many different namespaces, and there must be some way to say: "This is an declaration of the element E in the namespace N". XSD designers decided to design the language so that all declarations in the same schema document belong to the same namespace, called the target module namespace. It could be packaged in different ways, but the difference would be very superficial. What do you think is wrong with the decision to align modules with namespaces?