Инструменты, правила или процессы для проверки внутренней согласованности конфигурационных файлов XML

Question

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

В данном случае я имею в виду не строгую согласованность схемы XML, а скорее отношение более высокого уровня между используемыми узлами. Большинство проблем было вызвано неявной связью между информацией, закодированной в XML, и неявной связью этой информации с базой кода. Примеры могут быть:

• Данные узла XML неявно связаны с перечислениями в коде
• Бизнес-объекты в той же конфигурации, которые связаны (в том смысле, что они обмениваются информацией, которая должна быть согласованной) без какой-либо явной связи между ними
• Код в XML для компиляции и анализа во время выполнения

Меня поразило, что а) это может стать практикой увеличения частоты и б) что в некоторых случаях мы неявно создаем новый язык кодирования, который не проверяется во время компиляции - и на самом деле вообще имеет мало проверок он запущен.

Кто-нибудь еще сталкивался с подобными сценариями, и есть ли какие-либо инструменты или подходы, которые делают проблему более разрешимой? Я хотел бы привести несколько общих примеров, не зависящих от технологий - мой собственный опыт работы с C # и с config для проприетарных систем.

Примечание: хотя у меня есть ответ на этот вопрос ниже, я не собираюсь принимать свой окончательный ответ.

Answer 1

Я использую автоматизированные функциональные тесты для обеспечения целостности данных нашей конфигурации по умолчанию на работе.Я не знаю, что проблема, которую вы описываете, обязательно зависит от формата конфигурации XML.При этом я бы предложил:

• Вы не используете XML в качестве формата конфигурации.(Google может указать вам причины)
• Тесная связь через неявное использование перечислений или любых других созданных значений в конфигурации так же плоха, как и в коде.
• Код, который извлекаетсяиз конфига и выполненных заставляет меня съеживаться.Это в конфиге, чтобы его можно было переопределить?Если это так, то это огромный вектор для ошибок, неопределенного поведения и потенциальных проблем безопасности.
• проблема бизнес-объектов также звучит как плохая тесная связь.

Возможно, вы ничего не сможете сделатьо XML как формате конфигурации, плохом соединении или выполнении кода из конфигурации.Вы можете снизить риск, создав набор функциональных тестов, которые гарантируют:

• допустимые перечисления
• код компилируемый, исполняемый, не содержит evals, вызовов rpc,не вызывает функции или любые другие аналитические проверки, которые вы хотите добавить.

Вы также можете иногда помочь изменить, предоставив альтернативу (config или config config).

Answer 2

Вы пробовали Schematron? http://www.schematron.com/

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

См. Также Википедию: http://en.wikipedia.org/wiki/Schematron

Answer 3

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

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

Например, при использовании Java и Spring Framework существует плагин Eclipse под названием Spring Tool Suite , который может выполнять проверку синхронизации между конфигурацией XML и фактическим кодом.

Но это всего лишь один пример для конкретного языка и конкретной среды. Вы должны попытаться выяснить, существует ли что-то похожее для вашего сценария.

Кстати, если вы сообщите нам, какие технологии вы используете, мы могли бы помочь вам больше.

Answer 4

Хорошая ссылка от @David Peleg's - Topologi , которая предлагает продукты для проверки XML, включая проверки «бизнес-правил».