如何在不使收件人更改其架构的情况下将字段添加到XML文档

Question

我有一个应用程序将相同的XML文档发送到许多系统。现在其中一个系统想要额外获得一个字段。 问题是如何将字段添加到文档并将其发送到所有系统而不会破坏其过程。在另一个工作中，如何让其他系统忽略添加的字段？

Answer 1

如果没有破坏现有收件人，则无法执行此操作，除非收件人的设计考虑到此类更改。

XML系统通常会指定“如果您不理解某个元素，然后忽略它”的策略，如果您有这样的策略，并且人们都遵循它，那么添加新的可选字段变得很容易。但是，如果没有这样的政策，或者如果它没有经过严格的测试，那么添加字段就有可能破坏。

在架构级别，可以将新字段添加为可选元素或属性。如果扩展是针对特定客户端或客户端组的自定义，那么您可能需要考虑将额外的元素或属性放入不同的命名空间中，以便它们不会与其他人发明的扩展冲突。这还允许您利用XSD架构通配符，使任何内容有效，前提是它位于不同的命名空间中。

Answer 2

您可以将新添加的字段保留为可选字段。  请参阅此讨论What backward-compatible XSD changes can be made?了解详情

Answer 3

  

问题是如何将字段添加到文档并将其发送到   所有系统都没有破坏他们的过程？

这取决于。

• 如果您可以重新编译所有其他系统，并且这些系统已经生成了自动代码以使用XSD（例如，他们使用类似xsd.exe的.NET / C＃或类似的其他语言），然后你可以简单地修改架构。

  • 当使用自动代码生成时，由实际开发人员完成的剩余代码更改相对较小。由于生成模式更改所涉及的风险/时间主要由自动代码生成处理，因此对项目的影响很小。
  • 就个人而言，我赞成这条大型项目的路线，因为它允许在项目后期进行更改，风险很小。

• 如果您可以重新编译所有其他系统，但他们已经手工制作了＆＃34;用于解释和验证XML的代码，还有很多工作要做。这可能会阻止您在任何地方进行更改，但是：

  • 在整个系统中不进行普遍的变更开始增加工程债务。如果只更新了处理更改消息的某些系统，那么这将是未来遇到困难的一个方法。
  • 你是否可以＆＃34;侥幸逃脱它＆＃34;在短期内取决于迈克尔凯在他的优秀职位上讨论的政策。
• 如果您无法重新编译或修改其他系统，则可能会遇到严重问题。 XSD架构的重点在于它是每个系统都承诺遵循的商定标准。你想要违反合同，所以如果事情因此而破裂将是完全不足为奇的。

  

在不同的工作中，如何让其他系统忽略添加的内容   场？

迈克尔凯和诺曼汗已经解释/指出了关于你问题的这个特定方面的优秀建议。

一般点

自动生成POCO代码，POJO源代码（如果有）是帮助项目的绝佳方式。困难在于，可用于此的工具在质量和完整性方面各不相同。

我认为

xsd.exe非常好。我用过它，效果很好。

我为JSON模式尝试了C＃代码生成器。 JSON模式本身很好 - 您可以表达类型，结构和大小/值约束（就像XSD和ASN.1）。我试过的C＃代码生成器在没有涵盖完整的JSON模式标准方面令人失望。

我自己的经验主要是使用两种商业ASN.1工具。这些为ASN.1做了xsd.exe对XSD / XML的作用。但是它们比xsd.exe更有用，因为它们包括：

• C，C ++，C＃和Java
• 所有主要CPU和嵌入式系统上的所有主要操作系统，

ASN.1本身很有用

• 二进制（PER，BER等）wireformats
• text（XML，JSON等）有线格式。
  • 这允许与非ASN.1感知系统/语言的交互，例如， javascript，很多网页等等。
• ASN.1架构和XSD架构是可互换的。在两者之间存在转换的官方标准，ASN.1工具通常具有转换实用程序
  • 因此，使用ASN.1工具/模式/库构建的一个系统可以使用任何可用的XSD工具和库与使用XSD模式构建的另一个系统互操作，XML就是两者之间使用的线形格式。
  • ASN.1和XSD架构实际上是一个单一的真实点＆＃34;，两者之间的转换是自动的，也是构建过程的一部分。

如果有人可以访问这些工具，那么就可以拥有一个涉及各种不同语言，平台和技术的极其异构的系统，它们之间的接口全部都是机器生成的。

这些用于ASN.1的商业工具需要花钱（比如很多），但是对于在很多不同语言和平台上进行大量复杂消息交互的大型项目来说，节省人力和价值是值得的。降低风险。

当遇到与您类似的问题时，我几乎可以在项目中的任何一点进行架构更改，只需要很少的人力（通常低至几分钟）来处理整个系统的后果。