1）我意识到命名空间是区分使用XML Schema指定的不同模式/词汇表的一种方法，但我不明白为什么在命名空间（模式为其开发词汇表）中指定名称空间是个好主意。架构本身（通过targetNamespace属性）。
a）如果我们能够将特定命名空间与实例文档中的特定词汇/模式相关联，那会不会更好？那样那些编写实例文档就可以完全自由地将模式与他们想要的任何命名空间名称相关联？！
b）我在指定目标命名空间的模式中看到的唯一好处是，它的创建者可以选择将文档放在命名空间的末尾，该文档可以描述该命名空间的元素（假设模式使用命名空间的URL）。还有其他好处吗？ 2）如果架构没有targetNamespace，则必须使用noNamespaceSchemaLocation属性而不是schemaLocation属性（在实例文档中）引用特定架构。
如果说文档实例只是指定模式的位置并让XML模式验证器确定模式是否指定targetNamespace，那会不会更简单？
谢谢
答案 0 :(得分：2)
我只知道XML Namespaces的一个定义和http://www.w3.org上的XML Schema定义的一个定义。由于XML Schema非常复杂，因此我们将XML标准分为三部分Schema Part 0: Primer Second Edition，XML Schema Part 1: Structures Second Edition和XML Schema Part 2: Datatypes Second Edition。
如果您了解XML命名空间和XML架构的更多定义（更多“词汇表”），请发布您所指定义的链接。
任何模式根目录中targetNamespace的含义都很容易理解。 XML不是一种语言。这是一种元语言。 XML Schema帮助我们定义一种语言。我们必须为我们定义的语言（模式）提供唯一的名称。它是架构的targetNamespace。因此，有些文件应该被解释为用美国英语写的文件，它在GB英语中可能不太正确。
模式中的targetNamespace也是唯一的，在XML文件中，一个声明元素的名称空间，这意味着我们定义了编写文档的确切语言（和方言）的方式。在这种方式中，您也非常准确地说出应该解释相应名称的上下文。
如果定义不带targetNamespace的模式，则意味着XML文档中的相应元素和属性也必须属于“无名称空间”。 noNamespaceSchemaLocation属性或schemaLocation属性的使用不是必需的。所以你一定不能引用XML文档中的模式。在这种情况下，XML文档的读者应该从相应的上下文中知道您的模式。
在你的问题的最后，你问
如果相反，会不会更简单 文档实例只会指定 XML Schema的位置让我们来了 Xml Schema验证器搞清楚了 模式是否指定了 的targetNamespace？
但noNamespaceSchemaLocation属性的值正好是定义所用模式的XSD文件的路径。 schemaLocation属性的值是命名空间，XSD文件的路径除以空白。所以属性已经按照你的建议做了。
答案 1 :(得分：1)
您对命名空间“后期绑定”的想法并不错，但目前命名空间的一部分目的是允许处理器确定要使用的架构。
在这个过程中，“schemaLocation”属性只是一个提示，很多时候根本没用。
考虑以下情况：
在这种情况下，您可以说“让应用程序维护从命名空间到模式的映射，仍然没有理由在模式本身内指定命名空间”;遗憾的是，当架构将多个名称空间与导入混合时，这会导致问题。根据您选择的XML文件，您将在架构中创建名称冲突。
希望这是有道理的。
答案 2 :(得分：1)
指定目标名称空间的单个模式（或单词中的“词汇表”）的好处是它允许模式重用其他名称空间中的模式。
最常用的架构是http://www.w3.org/2001/XMLSchema，它定义了内置类型，如xs:int和xs:string。例如SAML Assertion重复使用http://www.w3.org/2000/09/xmldsig#和http://www.w3.org/2001/04/xmlenc#。
如果每个实例文档在不同的命名空间中定义xs:int，那将会非常混乱。像xs这样的前缀可以指定为实例的任何内容，因此如果需要，可以将其称为foo:int。但验证者需要知道最终它会解析为{http://www.w3.org/2001/XMLSchema}int。