我觉得我完全理解(简单)XML命名空间的概念。按照惯例，我们使用URI / URL，但是我们可以使用任何字符串，然后我们将其分配给一个前缀以供XML节点和属性重用，或者简单地作为范围的默认命名空间。到现在为止还挺好 ？
现在输入XML模式。由于某种原因，XML Schema的发明人认为简单命名空间的概念是不够的，他们不得不引入targetNamespace。我的问题是：targetNamespace引入了什么显着的好处，不能由普通的XML命名空间提供？如果一个XML文档引用一个xsd文档，无论是通过schemaLocation还是使用import语句，在任何一种情况下，我都给出被引用的实际xsd文档的路径。这是唯一定义我想要引用的模式。如果另外我想绑定这个模式到我的引用文档中的特定命名空间，为什么我必须复制已经定义在我引用的XML模式中的精确targetNamespace？为什么不能简单地重新定义这个命名空间，但是我想在XML文档中使用这个命名空间来引用我想要引用的特定XML模式文档？
更新：
举一个例子，如果我在一个XML实例文档中有以下：
<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>
为什么people.xsd模式需要定义一个targetNamespace，它是“http://contoso.com/schemas/People”？为什么我们需要在xsd文档中的targetNamespace定义？在我看来，所有你需要从命名空间部分获得的schemaLocation已经包含在XML实例文档中。在xsd文档中强制使用等价值的targetNamespace的存在的好处是什么？
跟随问题保罗的答案：
你能给我一个具体的例子，其中xsd元素名称之间的“冲突”变得明显，这将解释targetNamespace的需要？
好的，这里是试图回答我自己的问题。让我知道，如果它看起来与你一致。看看保罗联系的页面上的例子帮助了我。
如果我们在上面的原始问题中采用XML实例示例，我们有两个对车辆元素的定义的引用。一个是在XML实例文档本身中是显式的和可见的，但是我们还必须想象person.xsd XML Schema再次引用相同的车辆定义作为人的允许的子元素。如果我们要使用正常的命名空间，每个文档被允许为车辆定义自己的命名空间，我们将如何知道XML实例引用车辆的相同的XML模式定义，就像person.xsd？唯一的方法是通过执行比原始简单的命名空间概念更严格的命名空间概念，并且必须以跨多个文档完全相同的方式编写。
如果我不是在平板电脑上写这个，我会提供一个代码示例，但在这里我只是试图描述我的例子。
想象一下，我们有一个车辆元素的两个不同的XML模式定义。 location1 / vehicles.xsd将包含验证该帖子的问题(包含颜色，轮子和座位子元素)的示例的定义，而location2 / vehicles.xsd将包含车辆元素的完全不同的定义(例如，子元素年，模型和体积)。现在，如果XML实例文档引用位置1模式，如上例中的情况，但person.xsd表示person元素可以包含在location2模式中定义的类型的车辆子元素，则没有概念的targetNamespace，XML实例将验证，即使它明显没有适当的车辆作为其person元素的子元素。
目标命名空间然后帮助我们确保如果两个不同的文档引用相同的第三个XML模式，他们都在引用相同的模式，而不仅仅是一个模式包含相似但不相同的元素。 。
这有任何意义吗 ？
>在实例文档中，您使用XML命名空间来标识元素或属性所在的命名空间。
>在模式文档中，您声明将出现在实例中的元素和属性。它们声明为什么命名空间？这是targetNamespace的用途。
>模式文档位置和命名空间不一样。有相同的targetNamespace的多个.xsd文档是很常见的。 (他们可能或可能不包括彼此，但通常会包括彼此。)
>实例文档不总是有一个xsi：schemaLocation元素来告诉解析器在哪里定位模式。可以使用各种方法来告诉解析器在何处定位相关的模式文档。 XSD可以位于本地磁盘或某个Web地址，并且这不应影响其中的元素的命名空间。
> xsi：schemaLocation是一个提示。解析器可能会将给定命名空间的模式定位在其他位置，这意味着它们必须能够知道模式的命名空间。
>工具，如数据绑定工具，将预编译模式并生成识别有效文档的代码。这些必须能够知道声明的元素的命名空间。
我想你的假设是，实例文档可以指定在一些模式文档中声明的元素和属性的命名空间，使用xsi：schemaLocation。这不工作。一方面，解析器可以定位除了列出的那些之外的其他模式文档，并且它需要知道它们是什么命名空间。另一方面，它会使关于模式的推理变得困难或不可能：你将无法查看模式并知道一切属于的命名空间，因为该决定将被推迟，直到写入一个实例。
