为什么我们需要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文档的路径.这是唯一定义我要引用的架构的东西.另外，如果我想将此架构绑定到引用文档中的特定名称空间，为什么我必须复制我正在引用的XML架构中已经定义的精确targetNamespace?为什么我不能简单地重新定义此名称空间，但是我想在XML文档中使用该名称空间来引用我要引用的特定XML模式文档呢?

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模式需要定义一个目标名称空间，该目标名称空间是"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 ?

有关保罗的回答的后续问题:

Follow-up question to Paul's answer:

您能给我一个具体的例子，其中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实例示例，那么我们有两个对vehicle元素定义的引用.一个在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.

想象一下，我们有一个用于Vehicle元素的两个不同的XML Schema定义. location1/vehicles.xsd将包含验证该帖子问题示例的定义(包含颜色，车轮和座椅子元素)，而location2/vehicles.xsd将包含对车辆元素的完全不同的定义(例如，以及子元素年份，型号和体积).现在，如果XML实例文档引用了location1 Schema(如上例所示)，但是person.xsd表示person元素可以包含location2 Schema中定义的类型的vehicle子元素，则不包含该概念即使没有明显的正确的载具作为其person元素的子元素，该XML实例也将得到验证.

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可能位于本地磁盘上或某个网址上，这不应影响其中的元素的名称空间.
  • xsi:schemaLocation是一个提示.解析器可能会将给定名称空间的模式放在其他位置，这意味着它们必须能够知道该模式用于什么名称空间.
  • 诸如数据绑定工具之类的工具将预编译架构并生成可识别有效文档的代码.这些必须能够知道已声明元素的名称空间.
  • Within an instance document, you use XML namespaces to identify the namespace that an element or attribute is in.
  • Within a schema document, you declare elements and attributes that will appear in instances. What namespace are they declared to be in? This is what targetNamespace is for.
  • The schema document location and the namespace are not the same thing. It is quite common to have multiple .xsd documents with the same targetNamespace. (They may or may not include each other, but typically will include each other.)
  • Instance documents do not always have an xsi:schemaLocation element to tell parsers where to locate the schemas. Various methods may be used to tell a parser where to locate relevant schema documents. An XSD may be located on local disk or at some web address and this should not affect the namespace of the elements in it.
    • xsi:schemaLocation is a hint. Parsers may locate the schema for the given namespace elsewhere, which implies that they must be able to know what namespace a schema is for.
    • Tools, such as databinding tools, will precompile schemas and produce code that recognizes valid documents. These must be able to know the namespaces of the declared elements.

    我认为您假设的是，实例文档可以使用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屋！