Удаление дополнительных элементов из XML при недопустимости

Question

У меня есть кусок xml, который содержит необязательные неперечислимые элементы, поэтому проверка схемы не вызывает недопустимых значений. Однако после проверки этот xml преобразуется в другой формат и затем передается системе, которая пытается сохранить информацию в базе данных. На данный момент некоторые из значений, которые были факультативными в предыдущем формате, теперь являются закодированными значениями в базе данных, которые будут вызывать исключение ограничения внешнего ключа, если мы попытаемся их сохранить. Итак, мне нужно создать процесс в приложении J2EE, который будет проверять набор значений xpaths на набор значений, которые допустимы в этих местах, и если они недействительны, либо удаляют их, либо заменяют/удаляют их, и их родителей в зависимости от по ограничениям схемы.

У меня есть пара вариантов, которые будут работать, но ни один из них не кажется очень элегантным/интуитивным решением.

Вариант № 1 будет включать выполнение работы в xslt 1.0. Прежде чем отправлять xml через xslt, запрашивать приемлемые значения и отправлять списки в качестве параметров. Затем поместите тесты в соответствующие места в xml, который сравнивает входящее значение с приемлемыми и генерирует xml соответственно.

Этот вариант не кажется многоразовым, но его можно было бы быстро реализовать.

Вариант № 2 будет включать Java-код и конфигурационный файл xml. Файл конфигурации xml будет отображать xpaths необходимых тестов, допустимые значения, значения по умолчанию (если применимо) и что вынимать из документа, если тесты терпят неудачу.

Этот вариант гораздо более многоразовый, но, вероятно, удвоит время, необходимое для его создания.

Итак, какой из них вы бы выбрали? Или у вас есть другая идея? Я открыт для всех предложений и хотел бы услышать, как вы справитесь с этим.

Answer 1

Звучит для меня как вариант 2 - это надстройка. У вас есть четкое представление о том, когда вы захотите повторно использовать эту функциональность? Если нет, YAGNI, то идите для более простого и простого решения.

Answer 2

Оба варианта приемлемы. В зависимости от ваших навыков и сложности вашего XML, я бы сказал, что для этого потребуется примерно столько же времени.

• Вариант 1 был бы, на мой взгляд, более гибким, более легким в обслуживании в долгосрочной перспективе.

• Вариант 2 может быть сложным в некоторых случаях, как определить конфигурационный файл для сложных правил и как его разобрать без необходимости писать сложный код? Можно сказать, я буду использовать посетителя dom4j, и я покончу с этим. Однако вариант 2 может стать излишне сложным imho, если вы имеете дело со сложной структурой XML.

Answer 3

Я согласен с этим. Казалось, что это была пограничная надстройка, но я боялся, что кто-то, услышав, что это было сделано, предположил бы, что она будет многократно использоваться и попытаться создать что-то, что использовало ее в будущем. Однако с тех пор меня успокоили, что это одноразовая сделка и, таким образом, будет идти с подходом xslt.

Спасибо всем за ваши комментарии/ответы!