为什么我们需要 targetNamespace? [英] Why do we need targetNamespace?
问题描述
我想了解在 XML Schema 和 WSDL 中使用的 targetNamespace 的用途.事实上，为了简单起见，让我们将这个问题限制在 XML Schema 上.
I would like to understand the purpose of targetNamespace as used both in XML Schema and in WSDL. In fact, to keep things simple, let's limit this question to XML Schema.
我觉得我完全理解(简单)XML 命名空间的概念.按照惯例，我们使用 URI/URL，但我们可以使用任何字符串，然后将其分配给前缀以供 XML 节点和属性重用，或者仅用作手头范围的默认命名空间.到目前为止，还好吗?
I feel like I fully understand the notion of (simple) XML namespaces. By convention we use URI/URLs, but we could use any string, which we then assign to a prefix for reuse by XML nodes and attributes, or use simply as the default namespace for the scope at hand. So far, so good ?
现在进入 XML 模式.出于某种原因，XML Schema 的发明者认为简单命名空间的概念是不够的，他们不得不引入 targetNamespace.我的问题是:targetNamespace 引入了普通 XML 命名空间无法提供的哪些显着优势?如果 XML 文档通过 schemaLocation 或使用 import 语句引用 xsd 文档，无论哪种情况，我都会给出被引用的实际 xsd 文档的路径.这是唯一定义我要引用的模式的内容.另外，如果我想将此 Schema 绑定到我的引用文档中的特定命名空间，为什么我必须复制已经在我引用的 XML Schema 中定义的精确 targetNamespace?为什么我不能简单地在 XML 文档中重新定义这个命名空间，但是我想在其中使用这个命名空间来引用我想要引用的特定 XML Schema 文档?
Now enters XML Schema. For some reason the inventors of XML Schema felt the notion of simple namespaces wasn't enough and they had to introduce the targetNamespace. My question is : what significant benefit does a targetNamespace introduce that couldn't be provided by a normal XML namespace ? If an XML document references a xsd document, either by schemaLocation or with an import statement, in either case I give the path to the actual xsd document being referenced. This is what uniquely defines the Schema I want to refer to. If in addition I want to bind this Schema to a particular namespace in my referencing document, why should I be obliged to replicate the precise targetNamespace already defined in the XML Schema I am referencing? Why couldn't I simply redefine this namespace however I want within the XML document in which this namespace will be used to refer to that particular XML Schema document I want to reference ?
更新:
举个例子，如果我在一个 XML 实例文档中有以下内容:
To give an example, if I have the following in an XML instance document:
<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 有什么好处?
Why does e.g. the people.xsd Schema need to define a targetNamespace which is "http://contoso.com/schemas/People"? Why do we need the targetNamespace definition in the xsd document at all? It seems to me all you have to gain from the namespace part of the schemaLocation is already contained in the XML instance document. What is the benefit of enforcing the existence of a targetNamespace with equal value over in the xsd document ?
保罗回答的后续问题:
您能否给我一个具体的例子，其中 xsd 元素名称之间的这种冲突"变得很明显，这可以解释 targetNamespace 的必要性?
Can you give me a concrete example where such "clashes" between xsd element names becomes apparent and that would explain the need for targetNamespace ?
好的，这里尝试回答我自己的问题.让我知道它是否对你来说是连贯的.查看 Paul 链接的页面上的示例对我有帮助.
Ok, here's an attempt to answer my own question. Let me know if it seems coherent to you. Looking at the examples on the page linked by Paul helped me.
如果我们以上面原始问题中的 XML 实例为例，我们有两个对车辆元素定义的引用.一个在 XML 实例文档本身中是显式且可见的，但我们还必须想象 person.xsd XML Schema 再次引用相同的车辆定义作为 person 的允许子元素.如果我们要使用允许每个文档为车辆定义自己的名称空间的普通名称空间，我们怎么知道 XML 实例引用了与 person.xsd 相同的车辆 XML Schema 定义?唯一的方法是强制执行一个命名空间的概念，它比原来的简单命名空间更严格，并且必须在多个文档中以完全相同的方式编写.
If we take the XML instance example in the original question above, we have two references to the definition of the vehicle element. One is explicit and visible in the XML instance document itself, but we must also imagine that the person.xsd XML Schema references the same vehicle definition again as an allowed child element of person. If we were to use normal namespaces where each document were allowed to define its own namespace for vehicle, how would we know that the XML instance is referencing the same XML Schema definition for vehicle as is the person.xsd ? The only way is by enforcing a concept of namespace which is stricter than the original simple one and which must be written exactly the same way across multiple documents.
如果我不是在平板电脑上写这篇文章，我会提供一个代码示例，但在这里我将尝试描述我想到的示例.
If I wasn't writing this on a tablet I would provide a code example, but here I will just attempt to describe the example I have in mind.
想象一下，对于一个车辆元素，我们有两个不同的 XML 模式定义.location1/vehicles.xsd 将包含验证本文问题示例的定义(包含颜色、车轮和座椅子元素)，而 location2/vehicles.xsd 将包含一个完全不同的车辆元素定义，(例如, 带有子元素 year、model 和 volume).现在，如果 XML 实例文档引用 location1 Schema，就像上面的例子一样，但是 person.xsd 说 person 元素可以包含 location2 Schema 中定义的类型的车辆子元素，那么没有这个概念对于 targetNamespace，XML 实例会进行验证，即使它显然没有正确的车辆类型作为其 person 元素的子元素.
Imagine that we have two different XML Schema definitions for a vehicle element. location1/vehicles.xsd would contain the definition that validates the example from the question of this post (containing color, wheels, and seats child elements), whereas location2/vehicles.xsd would contain an entirely different definition for a vehicle element, (say, with child elements year, model, and volume). Now, if the XML instance document refers to the location1 Schema, as is the case in the example above, but person.xsd says that the person element can contain a vehicle child element of the type defined in the location2 Schema, then without the notion of a targetNamespace, the XML instance would validate, even though it clearly doesn't have the right kind of vehicle as a child element of its person element.
然后，目标命名空间帮助我们确保如果两个不同的文档引用相同的第三个 XML Schema，它们实际上都引用了相同的 Schema，而不仅仅是一个包含相似但不相同的元素的 Schema另一个...
Target namespaces then help us make sure that if two different documents are referencing the same third XML Schema, that they are both in deed referencing the same Schema and not just a Schema that contains elements that are similar, but not identical to one another...
这有意义吗?
推荐答案
你似乎走在了正确的轨道上.我将在这里提出几点可能会有所帮助.
You seem to be on the right track. I'll make a few points here that might help.
- 在实例文档中，您使用 XML 命名空间来标识元素或属性所在的命名空间.
- 在架构文档中，您声明将出现在实例中的元素和属性.他们声明在哪个命名空间中?这就是 targetNamespace 的用途.
- 架构文档位置和命名空间不是一回事.具有相同 targetNamespace 的多个 .xsd 文档是很常见的.(它们可能相互包含也可能不包含，但通常会相互包含.)
- 实例文档并不总是有一个 xsi:schemaLocation 元素来告诉解析器在哪里定位模式.可以使用各种方法来告诉解析器在哪里定位相关的模式文档.XSD 可能位于本地磁盘或某个 Web 地址上，这不应影响其中元素的命名空间.
- xsi:schemaLocation 是一个提示.解析器可能会在其他地方找到给定命名空间的架构，这意味着他们必须能够知道架构用于哪个命名空间.
- 数据绑定工具等工具将预编译架构并生成可识别有效文档的代码.这些必须能够知道所声明元素的命名空间.
我认为您的假设是实例文档可以使用 xsi:schemaLocation 指定在某些模式文档中声明的元素和属性的命名空间.那是行不通的.一方面，解析器可能会找到其他模式文档而不是列出的那些，并且它需要知道它们用于什么名称空间.另一方面，这会使关于模式的推理变得困难或不可能:您将无法查看模式并知道所有内容所属的命名空间，因为该决定将被推迟到编写实例之前.
I think what you were assuming is that the instance document could specify the namespace of the elements and attributes declared in some schema document, using xsi:schemaLocation. That doesn't work. For one thing, the parser may locate other schema documents than those listed, and it needs to know what namespace they are for. For another, it would make reasoning about schemas difficult or impossible: you wouldn't be able to look at a schema and know the namespaces that everything belonged in because that decision would be postponed until an instance was written.
这篇关于为什么我们需要 targetNamespace?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
