| So far, namespaces have only been dealt with as they relate to the schema processor and schema language itself. But the schema specification was written with the intention that schemas could support and describe XML namespaces. 17.3.1 Target Namespaces Associating a schema with a particular XML namespace is extremely simple: add a targetNamespace attribute to the root xs:schema element, like so: <xs:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema" targetNamespace="http://namespaces.oreilly.com/xmlnut/address">
 | It is important to remember that many XML 1.0 documents are not associated with namespaces at all. To validate these documents, it is necessary to use a schema that doesn't have a targetNamespace attribute. When developing schemas that are not associated with a target namespace, you should always explicitly qualify schema elements (like xs:element ) to keep them from being confused with global declarations for your application. | |
However, making that simple change impacts numerous other parts of the example application. Trying to validate the addressdoc.xml document as it stands (with the xsi:noNamespaceSchemaLocation attribute) causes the Xerces schema processor to report this validity error: General Schema Error: Schema in address-schema.xsd has a different target namespace from the one specified in the instance document :.
To rectify this, it is necessary to change the instance document to reference the new, namespace-enabled schema properly. This is done using the xsi:schemaLocation attribute, like so: <fullName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://namespaces.oreilly.com/xmlnut/address address-schema.xsd" language="en">Scott Means</fullName>
Notice that the schemaLocation attribute value contains two tokens. The first is the target namespace URI that matches the target namespace of the schema document. The second is the physical location of the actual schema document. Unfortunately, there are still problems. If this document is validated , the validator will report errors like these two: Element type "fullName" must be declared. Attribute "language" must be declared for element type "fullName".
This is because, even though a schema location has been declared, the element still doesn't actually belong to a namespace. Either a default namespace must be declared or a namespace prefix that matches the target namespace of the schema must be used. The following document uses a default namespace: <fullName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://namespaces.oreilly.com/xmlnut/address address-schema.xsd" xmlns="http://namespaces.oreilly.com/xmlnut/address" language="en">Scott Means</fullName>
But before this document can be successfully validated, it is necessary to fix one other problem that was introduced when a target namespace was added to the schema. Within the element declaration for the fullName element, there is a reference to the nationality attribute group . By associating the schema with a target namespace, every global declaration has been implicitly associated with that namespace. This means that the ref attribute of the attribute group element in the element declaration must be updated to point to an attribute group that belongs to the new target namespace. The clearest way to do this is to declare a new namespace prefix in the schema that maps to the target namespace, and use it to prefix any references to global declarations: <xs:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema" targetNamespace="http://namespaces.oreilly.com/xmlnut/address" xmlns:addr="http://namespaces.oreilly.com/xmlnut/address"> . . . <xs:attributeGroup ref="addr:nationality"/> . . .
Now, having made these three simple changes, the document will once again validate cleanly against the schema. | | The obvious lesson from this is that namespaces should be incorporated into your schema design as early as possible. If not, there will likely be a large amount of cleanup involved as various assumptions that used to be true are no longer valid. | |
17.3.2 Controlling Qualification One of the major headaches with DTDs is that they have no explicit support for namespace prefixes since they predate the "Namespaces in XML" recommendation. Although "Namespaces in XML" went to great pains to explain that prefixes were only placeholders and only the namespace URIs really matter, it was painful and awkward to design a DTD that could support arbitrary prefixes. Schemas correct this by validating against namespace URIs and local names rather than prefixed names . The elementFormDefault and attributeFormDefault attributes of the xs:schema element control whether locally declared elements and attributes must be namespace-qualified within instance documents. Suppose the attribute attributeFormDefault is set to qualified in the schema, like this: <xs:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema" targetNamespace="http://namespaces.oreilly.com/xmlnut/address" xmlns:addr="http://namespaces.oreilly.com/xmlnut/address" attributeFormDefault="qualified">
Now, if addressdoc.xml is validated against the schema, the validator reports the following error: Attribute "language" must be declared for element type "fullName".
Since the default attribute form has been set to qualified , the schema processor doesn't recognize the unqualified language attribute as belonging to the same schema as the fullName element. This is because attributes, unlike elements, don't inherit the default namespace from the xmlns="... " attribute. They must always be explicitly prefixed if they need to belong to a particular namespace. The easiest way to fix the instance document is to declare an explicit namespace prefix and use it to qualify the element and attribute, as shown in Example 17-5. Example 17-5. addressdoc.xml with explicit namespace prefix <?xml version="1.0"?> <addr:fullName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://namespaces.oreilly.com/xmlnut/address address-schema.xsd" xmlns:addr="http://namespaces.oreilly.com/xmlnut/address" addr:language="en">Scott Means</addr:fullName>
The elementFormDefault attribute serves the same function in regards to namespace qualification of nested elements. If it is set to qualified , which is normal practice, nested elements must belong to the target namespace of the schema (either through a default namespace declaration or an explicit prefix). | 