Удаление необязательных элементов из XML, если они недействительны

Question

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

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

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

Эта опция не выглядит многократно используемой, но она будет реализована очень быстро.

Опция # 2 будет включать в себя код Java и файл конфигурации xml. Конфигурационный файл xml будет размещать xpath необходимых тестов, допустимые значения, значения по умолчанию (если применимо) и что можно извлечь из документа в случае неудачи тестов.

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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