假设我的公司有很多模式，一些用于web服务，一些用于其他目的。通过导入以及特定于应用程序的模式，许多模式中都使用了常见的类型定义。
立即更改，版本化和导出模式。
到目前为止，该公司使用SVN来存储架构文件。它们没有高效的结构，存在冗余和其他问题。文件和文件夹没有明确的层次结构。
问题1：使用SVN存储和版本XSD文件是一种好习惯。什么是另一种好方法？
问题2：我怎么能有效地构建文件？我想将它们组织在关联文件命名空间的文件夹中。
问题3：导出时，提供flattend副本（一个包含所有文件的文件夹）或根据命名空间保持文件夹hirarchy更常见吗？
答案 0 :(得分：6)
这是一条建议。
例如，请参阅OGC模式存储库：
这是最大的公共模式存储库之一，广泛用于GIS行业。这些模式远非完美，但他们已经学到了很多教训。
回答你的问题：
您应该分离＆＃34;规范版本＆＃34;架构和＆＃34;编辑版本＆＃34;或＆＃34;修订＆＃34;。发布后，您可能需要并行支持一个模式的多个版本。例如：
两者并行广泛使用。
所以你应该考虑＆＃34;规范版本＆＃34;进入存储库文件夹结构。
＆＃34;修订＆＃34;应该由版本控制系统处理。您可能（并且将）需要在已发布的版本中进行修复。
如果您的架构是公开的，将它们放入像GitHub这样的公共代码存储库中可能是有意义的。这将允许您的技术用户通过拉取请求向您发送修复程序。 （这是我喜欢的OGC模式功能。）社区输入可能非常重要。 XML Schema不是最容易处理的事情，即使是经验丰富的开发人员也会犯错误。社区将有助于使事情有效。
对您的架构使用semantic versioning。当前策略中的OGC在名称空间URI中使用MAJOR和MINOR，但不使用PATCH。因此，对于GML 3.2.1模式，名称空间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我会知道在哪里寻找架构。
拥有一个＆＃34;条目文件＆＃34;按规格，如下：
与结构和命名保持一致。
如果您在一个存储库中有许多相关模式，导入/包含另一个模式，请更好地使用相对链接。这将使其他人更容易下载和验证本地副本。
不要做变色龙图式。不要谷歌吧。每个规范都应该有自己的命名空间。没有变色龙进口。
不，不要做任何扁平的副本。为什么？只需提供对架构仓库的访问权限，以及包含所有架构的ZIP。
包含许可证，以便明确许可证的内容。
使用多种已知工具检查并编译您的模式。 Xerces，Oxygen，Xmlmind，XML Spy。 Java上的JAXB / XJC，C＃的xsd.exe，Python的PyXB。确保它能正常工作。
为您的架构提供XML示例。