为什么我们需要targetNamespace?

23 浏览
0 Comments

为什么我们需要targetNamespace?

我想理解在XML Schema和WSDL中使用的targetNamespace的目的。实际上,为了简单起见,让我们把这个问题限制在XML Schema上。

我觉得我完全理解了(简单的)XML命名空间的概念。按照惯例,我们使用URI/URL,但我们可以使用任何字符串,然后将其分配给一个前缀以便XML节点和属性重用,或者仅仅作为范围的默认命名空间使用。到目前为止,没问题吧?

现在进入XML Schema。由于某种原因,XML Schema的发明者觉得简单的命名空间概念不够,他们不得不引入targetNamespace。我的问题是:targetNamespace引入了什么重要的好处,普通的XML命名空间无法提供?如果一个XML文档引用了一个xsd文档,无论是通过schemaLocation还是通过import语句,我都会提供到实际xsd文档的路径。这是我想要引用的Schema的唯一定义。如果我还想将此Schema绑定到我引用文档中的特定命名空间,为什么我必须复制我引用的XML Schema中已经定义的精确targetNamespace呢?为什么我不能在将要引用该特定XML Schema文档的XML文档中根据自己的需求重新定义此命名空间呢?

更新:

举个例子,如果我在一个XML实例文档中有以下内容:


   John
   28
   59
   
      Red
      4
      2
   

为什么例如people.xsd Schema需要定义一个目标命名空间,即"http://contoso.com/schemas/People"?为什么我们需要在xsd文档中定义目标命名空间呢?在我看来,你通过schemaLocation中的命名空间部分所获得的一切都已经包含在XML实例文档中了。在xsd文档中强制存在具有相同值的目标命名空间有什么好处呢?

对Paul的回答的跟进问题:

你能给我一个具体的例子,解释这种xsd元素名称之间的冲突,并解释为什么需要目标命名空间吗?


好的,下面是我对自己问题的回答。如果你觉得有条理的话,请告诉我。看了Paul提供的链接页面上的例子帮助了我。

如果我们看一下上面原始问题中的XML实例示例,我们有两个对vehicle元素定义的引用。一个是明确可见的,在XML实例文档本身中,但我们还必须想象person.xsd XML Schema再次引用相同的vehicle定义,作为person的允许子元素。如果我们使用普通的命名空间,允许每个文档为vehicle定义自己的命名空间,我们如何知道XML实例引用的是与person.xsd相同的XML Schema定义的vehicle?唯一的方法是通过强制实施比原始简单命名空间更严格的命名空间概念,并且这个概念在多个文档中必须完全相同地书写。

如果我不是在平板电脑上写这个,我会提供一个代码示例,但在这里我只尝试描述我心中的例子。

想象一下,我们有两个不同的XML Schema定义,用于vehicle元素。location1/vehicles.xsd将包含验证上述问题示例(包含color、wheels和seats子元素)的定义,而location2/vehicles.xsd将包含一个完全不同的vehicle元素定义(例如,带有year、model和volume子元素)。现在,如果XML实例文档引用location1 Schema,正如上面的例子所示,但person.xsd说person元素可以包含一个vehicle元素,该元素的类型在location2 Schema中定义,那么在没有目标命名空间的概念的情况下,XML实例将验证通过,即使它明显没有正确类型的vehicle作为其person元素的子元素。

因此,目标命名空间帮助我们确保如果两个不同的文档引用了相同的第三个XML Schema,那么它们确实引用了相同的Schema,而不仅仅是包含相似但不完全相同的元素的Schema...

这有意义吗?

0
0 Comments

为什么我们需要targetNamespace?

targetNamespace的作用是定义XML实例文档中的命名空间,以及与之关联的模式文档中的命名空间。通过targetNamespace,我们可以确保XML实例文档中的元素与模式文档中的元素相匹配,从而实现有效的验证和数据结构定义。

在给定的示例中,targetNamespace的作用是指定了XML实例文档中的命名空间,同时与之关联的模式文档中也定义了相应的命名空间。通过匹配命名空间,可以确保实例文档中的元素与模式文档中的元素相符合。

targetNamespace的存在解决了以下问题:

1. 验证:通过指定targetNamespace,可以对实例文档进行验证,确保其中的元素与模式文档中的元素相匹配。

2. 数据结构定义:通过指定targetNamespace,可以在模式文档中定义所需的数据结构,从而确保实例文档中的元素按照定义的数据结构进行组织和使用。

可以将targetNamespace类比为主人举办派对时的客人名单,而实例文档中的xmlns则类似于客人佩戴的姓名标签。只要有客人名单(其中包含了一份他们的身份证明的复印件),无论何时遇到某个客人,都可以验证他们的身份。如果遇到佩戴的姓名标签与附带的参数不匹配,就会引发错误。

通过模式/实例文档,我们有以下信息:

模式文档:

targetNamespace="http://localhost:8080/scribble/xml/Person"

targetNamespace="http://localhost:8080/scribble/xml/Vehicle"

实例文档:

xmlns:p="http://localhost:8080/scribble/xml/Person"

xmlns:v="http://localhost:8080/scribble/xml/Vehicle"

也就是说,在派对上,任何地方遇到的以"v"为昵称的客人(除非有特殊规定),无论是在房子的任何楼层、后院还是泳池中,都必须与名单上名为"http://localhost:8080/scribble/xml/Vehicle"的客人的描述相匹配,否则就是入侵者。

这些特殊规定可能会说,只有当V紧邻P时,V才能出现,或者只有在V存在时,P才能出现。在这种情况下,只有当V在场时,P才能参与,而V可以在没有P的情况下随意移动。

通过匹配命名空间(默认或带前缀的命名空间),模式可以非常灵活地定义几乎任何所需的数据结构,并通过与TNS和关联的模式匹配来跟踪元素的位置。

因此,targetNamespace的存在和使用确保了XML实例文档中的元素与模式文档中的元素相匹配,并提供了有效的验证和数据结构定义。

0
0 Comments

为什么我们需要targetNamespace?

XML Schema是一种用于声明“词汇表”的语言,它可以在XML文档中定义和描述数据的结构和内容。XML Schema可以将词汇表标识为命名空间,通过在targetNamespace属性中指定命名空间。

根据XML Schema的设计者,简单的命名空间概念是不够的,所以他们引入了targetNamespace的概念。通过使用targetNamespace,可以将不同的定义分割到不同的文件中,以便于在多个项目中重复使用,并且可以更好地管理和版本控制这些定义。此外,如果不同的团队在不同的文件中工作,可能会出现名称冲突的问题,而使用不同的命名空间可以解决这个问题,并且可以清楚地知道每个定义来自哪个文件。

targetNamespace的作用是提供一个抽象层次,使得XML Schema可以更好地管理和组织定义,避免命名冲突,并且方便在不同的项目中进行重用。

希望这个回答对你有帮助!感谢Paul的快速回答!我会在我的原始问题中发布一个后续问题,以便保持讨论的广泛性,避免在评论区产生过多的讨论。顺便问一下,XMLSchema-instance是否有特殊的意义?顺便说一句,那个链接非常好,解释得很清楚。

0
0 Comments

为什么我们需要targetNamespace?

在实例文档中,我们使用XML命名空间来标识元素或属性所在的命名空间。

在模式文档中,我们声明将出现在实例中的元素和属性。它们声明在哪个命名空间中?这就是targetNamespace的作用。

模式文档的位置和命名空间并不相同。很常见的情况是有多个具有相同targetNamespace的.xsd文档。(它们可以包含或不包含彼此,但通常会包含彼此。)

实例文档并不总是有xsi:schemaLocation元素来告诉解析器在哪里找到模式。可以使用各种方法告诉解析器在哪里找到相关的模式文档。XSD文件可以位于本地磁盘或某个网址上,并且这不应影响其中元素的命名空间。

xsi:schemaLocation只是一个提示。解析器可能在其他地方找到给定命名空间的模式,这意味着它们必须能够知道模式所属的命名空间。

工具,如数据绑定工具,将预编译模式并生成识别有效文档的代码。它们必须能够知道声明元素的命名空间。

我想你假设实例文档可以使用xsi:schemaLocation来指定由某个模式文档声明的元素和属性的命名空间。这是不正确的。首先,解析器可能会找到其他未列出的模式文档,并且需要知道它们所属的命名空间。其次,这将使得对模式进行推理变得困难或不可能:你将无法查看模式并知道所有内容所属的命名空间,因为这个决定将被推迟到编写实例时。

0