我必须解决的问题如下：
给定一个使用 XSD（或理想情况下的 NVDL）架构"几乎验证"的 XML 文件，如何以编程方式"修复"该文件？
（"几乎验证"意味着某些元素将具有不允许具有的属性。保证不会有其他验证错误。"修复"仅意味着删除有问题的属性。
我尝试使用 Woodstox 的验证编写器，但由于某种原因，它不接受我的 XSD 为有效（当然，它对于多个导入和抽象类型非常复杂，但它是有效的）。
另一种方法是 XML 验证库，它生成一个输出，然后我可以解析/处理并用于标识需要删除的属性。
生产相同最终产品的任何其他方法也受到欢迎。
如果要"仅强制实施"属性，可以使用 XSLT 标识转换来过滤不需要的 attr 或添加缺少的属性。它绝不是问题的广泛解决方案，而是对属性问题的非常好的修复。
但请记住，在 XSLT 转换之后，属性的顺序可能会更改，因为属性的顺序不是 XML 的必需属性。
使用错误处理程序分析 XML，该处理程序捕获在"删除此属性"类型命令对象中检测到的"额外属性"错误。
然后，如果您将这些对象放在"读取 SAX"解析器和"使用 SAX 写入"接收器之间，或者在将 DOM 树重写为 XML 之前在 DOM 树上运行它们，则这是一个实现问题。
错误处理程序应处理错误，如果不希望它成为错误，则错误处理程序不应终止分析。 这将为您提供细粒度控制，只是以编写代码来捕获属性在文档中的位置（并在以后对其进行处理）为代价。
根据 XML 规范，有效性约束只是"错误"，它为继续处理打开了大门，前提是您的错误处理程序不会停止游戏。 有关详细信息，请参阅第 1.2 节，这些详细信息表明这不应是不可恢复的错误，这意味着应该有可能使用捕获和修复解决方案。
对"其他方法"的回应。我宁愿修改 XSD 以接受任何其他属性：它会减少运行时开销，更不用说使用 XSLT 的所有管道了。
从它的声音来看，您知道并以某种方式理解/控制 XSD - 您听起来有信心说"保证没有其他验证错误"......因此，我的建议。
问题可能是如何修改XSD（如果它是"外部"的）。如果您能详细说明 XSD 是如何为您的处理而采购的，那么可能会出现更好的建议......
也许您最终仍然使用 XSLT 进行 XSD 到 XSD 的转换;在性能驱动的环境中，它仍然会更好，因为您必须对所有 XML 执行一次，而不是为每个 XML 执行一次。