我目前正在为此工作的公司将架构或合同版本编入根节点。例如，
<PurchaseOrder_v1_2 xmlns="http://someNamespace">
...
</PurchaseOrder>
我正在寻找人们对这种设计方法的看法，因为我不相信它是合理的。例如，它要求使用此模式作为消息传递合同的所有服务都能够发布多个版本以满足不同版本的客户端要求。
答案 0 :(得分：2)
我可能不同意@hacktick的建议，即命名空间的版本化是常规的。我从未见过W3C建议命名空间随版本而变化 - 当然W3C命名空间不会这样做 - 例如，两个版本的XSLT都有命名空间http://www.w3.org/1999/XSL/Transform。
将版本编码到根目录和命名空间都会更改元素的名称。在root的情况下，您实际上声明这是一个完全不同的元素，与先前版本中的PurchaseOrder元素没有定义的关系。在命名空间更改的情况下，您对该语言中的元素* all 说明了同样的事情。
版本属性更正常。我建议你在XML-dev邮件列表上阅读this thread，以获得一些非常明智的讨论吗？
答案 1 :(得分：1)
通常您会对架构的网址进行版本控制。
所以你会有一个名为“schema”的模式，然后你会像这样引用它：
“http://www.example.com/2011/01/schema”，其中2011和01是年份和月份形式的版本。
例如：
<PurchaseOrder xmlns="http://www.example.com/2011/01/schema">
</PurchaseOrder>
另一种方法是使用在根元素中指定版本。
例如，如果你的root元素被称为“PurchaseOrder”，你将添加一个必需的版本属性（“”）。您的版本属性将包含一个简单的数字，该数字随xsd的每个版本递增。您必须保存所有公共xsds的历史记录。这可能会导致更简单的xsd网址，但这些xml文件的提取和验证有点困难。
例如：
<PurchaseOrder version="1" xmlns="http://www.example.com/schema">
</PurchaseOrder>
如果您对根元素名称（“PurchaseOrder_v1_2”）进行版本化，那么如果您使用其他版本，则xml文件中会出现转换问题。
我个人会选择解决方案1（版本化命名空间）。这也是w3c推荐的。但是找不到这个陈述的链接。