我正在使用xmllint工具来检查一些XML文件与它们的XSD模式。似乎该工具被调用为
xmllint --noout --schema foo.xsd bar.xml
...并且不包括从XML文件的xsi:schemaLocation属性中检索XSD文件的选项。此外，在相关的 w3.org 规范中，有一个内容如下：
这些提示的存在 [即 xsi:schemaLocation ] 不需要处理器获取或使用引用的模式文档，并且处理器可以自由地使用通过任何合适的方式获得的其他模式，或者根本不使用模式。
那么可以公平地说，在实践中xsi:schemaLocation属性相当于（软）文档吗？此外，由于允许传入的 XML 文档告诉应用程序如何验证它们可能不是一个好的做法，我看不到它的好处。
当您因为不信任传入的文档而对其进行验证时，当然您想说明要用于验证的架构，而不是信任传入的文档来识别架构。
尽管如此，xsi:schemaLocation 被广泛使用，我认为大多数工具都支持它。我认为，在创作环境中，这是最有意义的，在这种环境中，作者基本上不相信自己在没有模式验证的帮助下就能正确地完成它。
但是，如果您将架构视为解释文档中的标记并帮助人们理解它的东西，那么它也是有意义的。它就像地图上的面板，解释了符号的含义：文档中使用的符号指南。
XSD 位置提示schemaLocation和noNamespaceSchemaLocation确实很少用于生产环境（我从未见过）。
我个人认为它是在开发阶段使用工具的一种便捷方法。它被认为是一种可互操作的方式来指示应使用哪些 XSD 进行验证、IntelliSense 等。
假设您构建了一堆 XML 文件（示例），以更好地说明（记录）另一堆 XSD 文件。据我所知，人们使用模式位置提示（相对 URI），压缩整个集合（XSD、XML 等），然后将存档发送给消费者。这样，无论人们使用什么开发工具，都有更多的机会实现“互操作”。例如，MS Visual Studio 维护了一个内部和专有的存储，它保存了特定 XML 文件的架构；“元数据”不能像 xsi 模式位置提示那样移植到其他工具。
我还看到了模式位置提示的一些真正“高级”的使用，这就是为什么至少在我们的工具中我们确实花费大量周期来阅读这些提示并动态调整智能感知和验证消息......