无效时从XML中删除可选元素

时间:2009-09-09 23:03:37

标签: java xml xslt xsd

我有一块包含可选的非枚举元素的xml,因此架构验证不会捕获无效值。但是,此xml在验证后会转换为不同的格式,然后传递给尝试将信息存储在数据库中的系统。此时,以前格式中可选的某些值现在是数据库中的编码值,如果我们尝试存储它们将抛出外键约束异常。因此,我需要在J2EE应用程序中构建一个进程,该进程将根据一组允许在这些位置允许的值来检查一组xpath值,如果它们无效,则删除它们/替换它们/删除它们和它们的父母取决于它们关于架构限制。

我有几个可行的选项,但它们都不是非常优雅/直观的解决方案。

选项#1 将涉及在xslt 1.0中完成工作。在通过xslt发送xml之前,查询可接受的值并将列表作为参数发送。然后将测试放在xml中的适当位置,将输入值与可接受的值进行比较,并相应地生成xml。

此选项似乎不是非常可重复使用,但实施起来非常快。

选项#2 将涉及Java代码和xml配置文件。 xml配置文件将布置所需测试的xpath,可接受的值,默认值(如果适用)以及如果测试失败将从文档中取出的内容。

此选项更可重用,但可能会使构建它所需的时间加倍。

那么,你会挑选哪一个?或者你有另一个想法?我对所有建议持开放态度,并希望听到你如何处理这个问题。

3 个答案:

答案 0 :(得分:1)

听起来像选项2过度工程。您是否清楚了解何时需要重用此功能?如果没有,YAGNI,那么寻求更简单,更容易的解决方案

答案 1 :(得分:1)

这两个选项都可以接受。根据您的技能和XML的复杂程度,我会说它需要大约相同的时间。

  • 从我看来,选项1更灵活,从长远来看更容易维护。

  • 在某些情况下,选项2可能很棘手,如何为复杂的规则定义配置文件本身,以及如何在不编写复杂代码的情况下解析它?有人可以说,我将使用dom4j访问者,我将完成它。 但是,如果您处理复杂的XML结构,选项2可能会变得不必要地复杂化

答案 2 :(得分:1)

我在此同意。感觉它是过度工程的边缘,但我担心听到这样做的人会认为它可以重复使用并尝试设计将来使用它的东西。但是,我已经放心,这是一次性的交易,因此,将采用xslt方法。

感谢所有人的意见/答案!