A schema defines a set of types, element, attributes, etc. These components are defined in a specific namespace if the targetNamespace attribute is specified, or in the empty namespace (or no namespace) if there are no targetNamespace attribute. Hence, the targetNamespace is essential to the semantics of your target XML documents: Do the elements live in a certain namespace or not?
The xmlns attribute in the schema is more or less a convenience thing and means nothing in terms of the semantics of your target documents. There are consequences in how you refer to data types and components within the schema.
Consider these two alternatives. In the first alternative the default namespace is the same as the target namespace.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com/animal" xmlns="http://www.example.com/animal"
elementFormDefault="qualified">
<xsd:simpleType name="Animal">
<xsd:restriction base="string">
<xsd:enumeration value="Dog" />
<xsd:enumeration value="Cat" />
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="animal" type="Animal" />
<xsd:element name="date" type="xsd:dateTime" />
</xsd:schema>
In the second alternative, the default namespace is the same as the XML Schema namespace. Note how the type references are "inverted".
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/animal"
xmlns:tns="http://www.example.com/animal" elementFormDefault="qualified">
<simpleType name="Animal">
<restriction base="string">
<enumeration value="Dog"/>
<enumeration value="Cat"/>
</restriction>
</simpleType>
<element name="animal" type="tns:Animal" />
<element name="date" type="dateTime" />
</schema>
However, regardless of the alternative, both <animal> and <date> lives in the http://www.example.com/animal
namespace. The document
<animal xmlns="http://www.example.com/animal" />
woudl be valid for bothalternatives.