假设我的公司有很多架构，一些用于网络服务，一些用于其他目的。通过导入在许多这些模式中使用了通用类型定义，也有特定于应用程序的模式。
时不时地更改、版本化和导出架构。
目前公司使用SVN来存储schema文件。它们的结构不高效，存在冗余和其他问题。文件和文件夹没有明确的层次结构。
问题 1:使用 SVN 来存储和版本化 XSD 文件是否是一种好的做法。什么是其他好的方法？
问题 2:如何有效地构建文件？我想将它们组织在与文件 namespace 相关的文件夹中。
问题3:导出时，是平铺(一个文件夹所有文件)还是根据命名空间保持文件夹层次结构更常见？
最佳答案
这里有一条建议。
例如，参见 OGC 架构存储库:
这是最大的公共(public)架构存储库之一，广泛用于 GIS 行业。这些模式远非完美，但他们已经吸取了很多教训。
回答您的问题:
您应该将架构的“规范版本”与“编辑版本”或“修订版”分开。一旦发布，您可能需要并行支持一个模式的多个版本。例如:
两者广泛并行使用。
因此您应该将“规范版本”纳入存储库文件夹结构。
“修订”应该由版本控制系统处理。您可能(并且将)需要对已发布的版本进行修复。
如果您的模式是公开的，那么将它们放入 GitHub 等公共(public)代码存储库中可能很有意义。这将允许您的技术用户通过拉取请求向您发送修复。 (这是我希望 OGC 模式具有的功能。)社区输入可能非常重要。 XML Schema 不是最容易处理的事情，即使是有经验的开发人员也会出错。社区将有助于使事情顺利进行。
请使用 semantic versioning为您的架构。当前策略中的 OGC 在 namespace URI 中使用 MAJOR 和 MINOR，但不使用 PATCH。因此，对于 GML 3.2.1 模式， namespace URI 是:
模式 URI 不必与命名空间 URI 相同(比较 http://schemas.opengis.net/gml/3.2.1/ 和 http://www。 opengis.net/gml/3.2)。如果您在文件夹中使用 MAJOR.MINOR.PATCH 而在命名空间中仅使用 MAJOR.MINOR - 那么这些 URI 在技术上什至不能相同。但应该有一个直接的转变。有了像 http://www.opengis.net/gml/3.2 这样的 URI，我就会知道在哪里寻找模式。
每个规范都有一个“入口文件”是很好的，就像这样:
与结构和命名保持一致。
如果您在一个存储库中有许多相关模式，相互导入/包含，最好使用相对链接。这将使其他人更容易下载和验证本地副本。
不要做变色龙模式。甚至不要谷歌它。每个规范都应该有自己的命名空间。没有变色龙进口。
不，不要做任何拼合的副本。为什么？只需授予对您的模式存储库的访问权限，再加上可能包含所有模式的 ZIP。
包括许可证，以便清楚许可证是什么。
使用多种已知工具检查和编译您的架构。 Xerces、Oxygen、Xmlmind、XML Spy。 Java 上的 JAXB/XJC，C# 上的 xsd.exe，Python 上的 PyXB。确保它在 OOTB 时有效。
为您的模式提供 XML 示例。
关于xml - 组织 XML 模式文件的最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29695959/