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