xml – 为什么我们需要targetNamespace？

我觉得我完全理解(简单)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模式，他们都在引用相同的模式，而不仅仅是一个模式包含相似但不相同的元素。 。

这有任何意义吗 ？