（实际上）XML模式和XML命名空间之间是否存在1：1的对应关系？

Question

我得到许多XML文档不使用命名空间或模式。我也明白你可以拥有一个使用命名空间而没有任何关联模式的XML文档（例如Log4J配置）。

虽然在技术上可以创建没有关联命名空间的XML模式，但几乎每个XML模式都不具备它自己唯一的目标命名空间吗？

也许有一些限制了多个名称空间，但我也想不出任何这样的例子。

后续问题：如果要对XML模式（及其URI）进行版本化，是否要对命名空间URI进行版本化？

Answer 1

如果某些XML数据的官方提供者未指定XML架构，则第三方可能仍会编写一个。在这种情况下，您可能最终会为同一名称空间使用多个XML Schema定义。

您甚至可能希望为命名空间的特定子集定义架构。

例如，当我编写一个仅允许使用HTML子集的CMS时（出于安全原因，例如没有<script>标签），一种方法是指定 new <script>标记，因为模式不允许它们。

Answer 2

模式可以描述多个名称空间。它必须从几个模式文档构建（使用xs：import），但它仍然是一个模式。

您也可以为同一名称空间使用多个不同的模式。例如，您可能希望对已发布的文档施加比草案文档更高的质量标准。

所以它根本不是1：1的关系。

Answer 3

这个答案主要与后续问题有关。

我见过的一种模式（通常在大型政府电子归档平台中）是采用模式的主要/次要版本编号策略。这里，次要版本增量表示不中断模式更改，主要版本增量保留用于中断更改。然后，名称空间URI仅包含主要版本号。

例如，假设您要公开其入站消息结构由submitStuff-v1-0.xsd定义的服务。这最初可能具有目标命名空间URI（例如）：

http://www.example.org/services/submitStuff/1

在v1.0发布后的某个时刻，我们引入了一个非破坏性的变化（例如添加一个可选元素）。这将导致submitStuff-v1-1.xsd的释放，但命名空间URI将保持为：

http://www.example.org/services/submitStuff/1

由于v1.1中引入的新元素是可选的，因此这种方法意味着如果服务的用户不需要提交新信息（如果命名空间需要他们需要这样做），则不会强制他们更新系统。 URI也包含次要版本）。虽然这对客户来说似乎是一个简单的改变，但它引入了提交和接收系统之间的额外耦合，这可能是不可取的。

如果在以后引入了重大变更（例如引入新的强制性要素），我们会submitStuff-v2-0.xsd使用新的命名空间：

http://www.example.org/services/submitStuff/2

该服务的客户端将能够在传入消息中明确断言他们是否尝试提交符合v1.x或v2.x的请求。

在过渡期间，服务提供商可能希望同时支持v1.x和v2.x消息，直到所有客户端都迁移到新的消息结构。通过将主要版本引入命名空间，可以区分以下场景：

• 文件管理器尝试提交v2.x消息，但错过了必需元素，在这种情况下应返回错误消息。
• 文件管理器已真正提交了v1.x消息，因为他们的系统尚未升级以生成v2.x消息，在这种情况下，不应返回任何错误。

还可以使用命名空间中嵌入的版本控制信息来执行基于内容的路由 - 例如，将所有新版本消息路由到一组新的处理服务器。