组织XML模式文件的最佳实践
假设我的公司有很多模式，一些用于web服务，一些用于其他目的。在许多这些模式中通过导入以及特定于应用程序的模式使用了常见的类型定义。组织XML模式文件的最佳实践
现在，然后架构被更改，版本化和导出。
到目前为止，该公司使用SVN来存储架构文件。他们没有高效率地组织，有冗余和其他问题。没有清晰的文件和文件夹。
问题1：使用SVN来存储和版本XSD文件是一种很好的做法。什么是其他好方法？
问题2：我如何有效地构造文件？我想将它们组织在关联文件名称空间的文件夹中。
问题3：导出时，给平铺副本（包含所有文件的一个文件夹）还是根据命名空间保留文件夹hirarchy更常见？
这是一条建议。
例如参见OGC模式库：
这是最大的公共架构库之一，广泛应用于GIS行业。模式远非完美，但他们已经吸取了很多教训。
回答您的问题：
你应该分开模式的“规范版本”和“社论版”或“修改”。一旦发布，您可能需要并行支持一个模式的多个版本。例如：
两种广泛使用的并联连接。
因此，您应该将“规格版本”纳入存储库文件夹结构中。
“版本”应由版本控制系统处理。您可能（也将会）需要在已发布的版本中进行修复。
如果你的模式是公开的，把它们放到像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，我会知道在哪里寻找模式。
这是件好事，每一个规范 “入口文件”，像这样的：
要与结构和命名是一致的。
如果在一个存储库中有许多相关的模式，导入/包含另一个存储库，那么最好使用相对链接。这会让其他人更容易下载和验证本地副本。
不要做变色龙模式。甚至不要谷歌它。每个规范都应该有自己的名称空间。没有变色龙进口。
不，不要做任何扁平化的副本。为什么？只需访问您的模式库，再加上一个包含所有模式的ZIP文件即可。
包含许可证以便清楚许可证是什么。
使用几种已知工具检查并编译您的模式。 Xerces，Oxygen，Xmlmind，XML Spy。 Java上的JAXB/XJC，C＃中的xsd.exe，Python中的PyXB。确保它可以工作OOTB。
为您的模式提供XML示例。
这是一个非常有用的见解，非常感谢。在版本3.2.1中，GML模式开始使用该版本作为targetNamespace的一部分。你会考虑将版本属性和改变后的目标命名空间的组合作为最佳实践，以及你如何处理细微变化 - 它们是否反映在版本中？我考虑过在版本属性中使用MAJOR.MINOR模式，而在命名空间中只使用MAJOR版本 - 只有当更改意味着逆向兼容性丢失时才更改命名空间。 – Alex
根据semver，他们实际上应该只包含MAJOR，因为事情应该在MINOR变更中向后兼容。我认为我最好坚持使用semver，因为它被广泛使用，而不是OGC的解释。不足之处在于，在许多向后不兼容的更改中，您将获得较高的MAJOR版本。这不是“营销” - 友好。 – lexicore
其他问题是：使用带有版本号的现有名称空间生成Java类时，Java包将发生更改，因此使用这些类的许多代码将需要更改（至少更改该代码中的导入语句）。相同的命名空间意味着不可能支持不同版本的课程。一些生成器允许定义独立或半独立包生成，但这也可能会造成混淆。仍然不确定“文件名中的版本”是否也可能是一种合理的方法（如在本白皮书中：http://www.xfront.com/SchemaVersioning.html）。 – Alex