HunterNomadmaytonПросто я акцентирую внимание на том что XML вовсе не human-readable.
Вопрос спорный. Возможно XML и не самый лучший вариант для human-readable но если применять human-readable теги, то с первого взгляда понятно:


Проблема в том, что xml в общем случае это очень длинный и сложный стек технологий
(возьмите хотя-бы processing instruction) и его обычно применяют для хранения
конфигов в веб-серверах да и то в "кастрированном" виде. Т.е. там где по смыслу
смело можно использовать атрибут - пихают элемент. В данном конкретном случае
попробую предположить что login не имеет потомков и выделяю его в атрибут.




Выходит более компактно. И концептуально. У меня вообще вызывает удивление "тотальное засилие"
XML-конфигов на фоне сегодня существующих более удобных JSON или YAML.
Или даже property-bag текстовых файлов. Как будто-бы человек (сисадмин)
это некое приложение к инфо-системе которое обязано помнить о теговой.

Те XML-документы которые созданы сериализацией объектов или прочими инструментами,
экспорта баз (особенно иерархических и сетевых) как правило нечитабельны.

svenomЭто утверждение применимо и JSON, и к YAML - при средних и больших размерах они точно так же нечитаемы.
Разумеется всё зависит от того кто писал и как. Но когда вы применяете
XML - для хранения конфигов - вы нацеливаете очень мощную пушку
на маленьких птичек. XML-сложен. Многоуровнев. Тяжёл для полноценного
использования. По его производным технологиям и схемам (xml-schemas)
для различных отраслей науки и технологии написаны терабайты
документации, консорциум пестрит стандартами, рекомендациями.
Он неоднозначен. Вы не сможете отобразить ваши структуры данных
как 1:1 в формат XML. Всегда будут варианты. Пространства имён
(namespaces) "ужасают" своим изначально громоздким синтаксисом
использования и делают практические попытки своего применения
нежизнеспособными хотя-бы из-за фактора банальной лени
разработчика. При прочих возможностях он избавится от этой
feature.

Cуществующие парсеры и XML-трансформеры не всегда совместимы друг с другом
и неоднозначно трактуют сами стандарты XML/XSLT. Благодаря блокам
processing-instruction в XML заложены БЕСКОНЕЧНО большие возможности
пред-обработки документа. И вообще, по выражению Дейта - XML
это попытка заново создать иерархические СУБД.

И еще немаловажно, XML болеет теми-же детскими болезнями что и
банальный текстовый файл. Update элемента или атрибута принципиально
невозможен без полного 100% переписывания (серализации файла). В совокупности
с дисковыми накладными расходами на массовость таких операций
создание XML-DBMS либо невозможно либо лежит не в плоскости XML
либо является фейком и рекламным ходом.

Лет 10 назад я был ярым сторонником использования XML там где это возможно.
Сейчас я охладел. И хотел-бы ограничиваться ровно тем чем можно решить
задачу. Забавно но самая реальная и полезная сфера применения
XML - электронная почта так и осталась им не завоёванной.

LeonidvТак принято в мире java. Я сходу не припомню сервисов в Linux, которые настраиваются через XML.
Лиха беда начало. Системные сервисы должны (я считаю) конфигуриться текстовыми/plain файлами
а вот KDE и прочие десктопы возможно подсадят на эту иглу.

В Apache configs также предпринята на мой взгляд нелепая попытка "впихнуть невпихуемое". Но это слава богу
древняя опция и надо надеяться что это не XML а что-то более реликтовое.

HunterNomadmayton ... У меня вообще вызывает удивление "тотальное засилие"
XML-конфигов на фоне сегодня существующих более удобных JSON или YAML.

Смотри. Существует xml (база данных клиентов (почему не в SQL? на то есть своя причина )) в, скажем, 100 000 строк. Чтобы Вырвать все или часть данных про Ali Baboo мне нужен только xslt филей.
А как это сделать в JSON или YAML. И я не думаю, что их (JSON или YAML) будет проще и быстрее редактировать чем xml.
Мы говорим про конфиги или базы данных? У меня по каждому вопросу отдельная точка зрения.

HunterNomadmaytonМы говорим про конфиги или базы данных? У меня по каждому вопросу отдельная точка зрения.
Прости, я ввел тебя (возможно и остальных ) в заблуждение. В проекте xml рассматривается как универсальный способ хранение данных. Будь то конфиги или база данных. Вот, как то так.
Я участвовал в разработке одной фронт-системки где XML-документ был единицей обработки данных.
Но у этой системы была масса ограничений на транзакции, конкуренцию. Она также
создавала нагрузку плохо совместимую с объёмом обрабатываемых данных.
Пожалуй единственное преимущество этой системы это отсутствие зависимости
от БД. Но все отрицательных факторы сильно смещали чашу весов этого преимущества
в другую сторону. По сабжу, я "кинул" этот проект и поменял работу.
Настолько моё идеологическое неприятие было сильно.

Там где нужен сильный интеллект в вопросах - найти и обработать и извлечь из 1-10
документов данные - XML-XSLT хорош. А там где нужна массовость и скорость - он ненужен.
Если ваши данные имеют реляционное отображение то извинительнее взять
какой-нить MS(XE) или Oracle(XE) и решить данную задачу без мозгоёбства.

Если тебя интересует вообще хардкорная оптимизация трансформаций то можно
почитать про устройство Intel® XSLTAccelerator 1.1. Не знаю живо оно сейчас
и где используется но как факт - такое было создано.

http://cache-www.intel.com/cd/00/00/34/42/344227_344227.pdf

Но это так. Для общего развития.