Is xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" a special case in XML?

When we use a namespace, we should also indicate where its associated XSD is located at, as can be seen in the following example:

<?xml version="1.0"?>
<Artist BirthYear="1958" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://www.webucator.com/Artist开发者_开发技巧"
 xsi:schemaLocation="http://www.webucator.com/Artist Artist.xsd">
 <Name>
  <Title>Mr.</Title>
  <FirstName>Michael</FirstName>
  <LastName>Jackson</LastName>
 </Name>
</Artist>

Here, we have indicated that Artist.xsd should be used for validating the http://www.webucator.com/Artist namespace. However, we are also using the http://www.w3.org/2001/XMLSchema-instance namespace, but we have not specified where its XSD is located at. How do XML parsers know how to handle this namespace?

Update (in response to the first commenter)

So, can we instead of using:

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ehcache="http://www.springmodules.org/schema/ehcache"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 
            http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
            http://www.springmodules.org/schema/ehcache
            http://www.springmodules.org/schema/cache/springmodules-ehcache.xsd">
...
</beans>

use

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ehcache="http://www.springmodules.org/schema/ehcache">
...
</beans>

?

---

How do XML parsers know how to handle this namespace?

They don't, except when they do. The basic idea is that the string 'http://www.w3.org/2001/XMLSchema-instance' works like a magic cookie. Either the processing software has been programmed to recognize it, and thus act on the basis of what it means, or it has not.

Thus, with the mere fact of recognition also comes the "knowledge" of what it represents: a "namespace" that defines four attributes ('type', 'nil', 'schemaLocation' and 'noNamespaceSchemaLocation') with fixed predefined meanings.

In other words, if you "know" what the string 'http://www.w3.org/2001/XMLSchema-instance' "means", then you also automatically know what an attribute named xsi:schemaLocation "means": that it points to schema documents encoded in the 'W3C XML Schema' formalism.

This goes beyond what the XML Namespaces Rec actually provides for (which is only some handwaving about "universal names" or whatnot). A convention is at work here, that the syntax of namespacing (using colonified names) has been deployed to hard-code a semantic understanding: "where to find the schema, in the formalism of W3C XML Schemas, for this document instance." It all hinges on prior understanding of that magic cookie string.

You may be under the impression that a namespace must have a schema, and a machine processable one at that, and only in the W3C XML Schemas formalism to boot. None of these are necessarily true. Other schema formalisms exist (SGML/XML DTDs, Relax-NG, both of which, unlike W3C XML Schemas, are international standards); a namespace definition does not have to be machine-readable (it could be prose, as in fact it is for the 'http://www.w3.org/2001/XMLSchema-instance' namespace!); and a namespace need not be formally defined at all, because all a namespace string is guaranteed to do is to function as a disambiguation marker.

---

There's no requirement to say where the schema is located. You can do it if you want, but you don't have to.

In this example, all platforms are likely to understand where the schemas for xsi, xml, xsd and soap are all located.

---

EDIT: Like I said, all platforms are likely to know where the schemas are for these well-known namespaces. Quite likely, they all have copies of the schemas. I use Visual Studio, and it keeps copies of these schemas online, and refers to them as necessary.

---

There are four built in declarations for Xml schemata; type, nil, schemaLocation and noNamespaceSchemaLocation as are "present in every schema by definition." You can read about them in the Xml Schema recommendation.

---

If you look to content of: http://www.w3.org/2001/XMLSchema-instance you found that there is text:

...
<xs:schema targetNamespace="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns="http://www.w3.org/1999/xhtml">
  <xs:annotation>
   <xs:documentation>
    <h1>XML Schema instance namespace</h1>
    <p>See <a href="http://www.w3.org/TR/xmlschema-1/">the XML Schema
       Recommendation</a> for an introduction</p>
...

Because xmlns="http://www.w3.org/1999/xhtml" you see above link as HTML document.

According to http://www.w3.org/TR/xmlschema-1/#schema-loc (Schema Representation Constraint: Schema Document Location Strategy) schema-aware processors may implement any combination of the following strategies, in any order:

• Attempt to resolve the namespace name to locate such a resource.

So http://www.w3.org/2001/XMLSchema-instance point to itself (yea, recursion!!).

See similar answer: Where is the XSD file for "http://www.w3.org/2001/XMLSchema-instance"?

PS. Any specialized XML processor can treat http://www.w3.org/2001/XMLSchema-instance as known thing without actually download this definition (and most do that).

PPS. Semantic of http://www.w3.org/2001/XMLSchema-instance defined by XML Schema standard http://www.w3.org/TR/xmlschema-1/