Горизонтально, вертикально и вперемешку
Недавно очень ясно осознал на собственном опыте, насколько же разными могут быть структурные модели XML. Разные они и по восприятию, и удобству обработки, и простоте создания. Но о вопросах генерации я могу только догадываться и предполагать, поскольку особо этим не занимался никогда, то про обработку могу действительно поделиться некоторыми мыслями, которые меня посетили после продолжительного периода “ковыряния” различных XML структур данных.
Горизонтальная модель показалась мне более читаемой. Т.е. она более похожа на табличные выборки из баз данных. И как не странно, её проще парсить и обрабатывать. Ставка на атрибуты, идентификаторы которых уникальны в приделах одного элемента, себя оправдывает и не порождает излишеств.
Вертикальная модель подразумевает активное использование дочерних элементов. Из-за этого документ получается более “толстым”. Причем зачастую. использование дочерних элементов не очень оправдано. Они не используются как контейнеры для других элементов и даже CDATA
там не хранится. А читать труднее. Хотя и появляется некая древовидная структура, но достаточно вырожденная и почти плоская. Ну и много “паразитной” разметки получается как следствие.
На практике выходит, что придерживаться только одного стиля не получает у схема-составителей. Обычно приходится иметь дело с гибридной моделью. Где вполне себе подчиненные логике мета-данные вынесены в атрибуты, другие же почему-то в дочерние элементы. Иногда кажется, что просто для разнообразия. Кому-то режет глаз, если элемент это длинная строчка с неким набором атрибутов и для гармонии обязательно нужно чтобы что-то было внутри самого элемента. Надо признать, что удобства в обработке и чтении это тоже не добавляет.
Кстати, достаточно просто можно определить насколько XML модель соответствует внутренней модели данных в базе и насколько данные трансформировались и адаптировались для XML’ного представления. Когда вы работаете со структурой, которая полностью соответствует классической нормализованной схеме базы данных, то сразу понимаете, что XML является практически “снимком” данных этой базы. Да, генерация заметно упрощается, но это ставит крест на читаемости и удобстве обработки принимающей стороны. Разгребать ворохи “ссылок” и странных идентификаторов - каторга.
Под чтением я понимаю, именно чтение человеком, т.е. мной. Я приверженец того мнения, что XML не для чтения и написания самим человеком, тем более, когда многие об удобстве забывают и генерируют ужасные схемы. Это машинный формат и то что он текстовый это всего лишь деталь реализации и одна из особенностей, а не параметр, который сразу записывает его в легко-человеком-воспринимаемые форматы. Воспринимать вертикальный и сильно “нормализованный” документ сложно. Конечно можно привыкнуть, но не стоит. По крайней мере один раз прочесть документ надо - для того чтобы написать конвертер в свои бизнес объекты. А потом забыть и доверить генерацию/потребление на откуп программе. Отсюда вывод: не надо делать, например, конфигурационные файлы на база XML и уже тем более не стоит делать на его основе мало-мальски сложные DSL. Пусть на XML’е разговаривают программы. Но это мнение не все, увы, разделяют. Ant тому пример - популярен бешено, хоть в определенной среде, где XML культ.
XML вызывает у меня радугу эмоций. Это не плохо на самом то деле…