Форматтер XML

Форматтер, построенный на регулярных выражениях — вставляющий перенос строки перед каждым `<` и расставляющий отступы на основе текущего счётчика открытых тегов, — работает более-менее приемлемо на простом, написанном вручную XML и даёт сбой на реальных документах по причинам, которые легко упустить из виду, пока они не приведут к повреждённому файлу. Секция CDATA, записанная как `<![CDATA[...]]>`, существует специально для хранения произвольного текста, который сам может содержать символы, похожие на теги, и регулярное выражение, ищущее `<`, никак не может знать, что должно игнорировать всё между этими маркерами, а не воспринимать содержимое как структуру. Комментарии несут тот же риск, а значения атрибутов ещё хуже: атрибут вроде `note="a > b"` содержит буквальный символ `>`, который наивный сканер может принять за конец тега, незаметно обрезав его не в том месте.

Правильное форматирование XML означает, что сканер должен распознавать эти особые области — блоки CDATA, комментарии, инструкции обработки, объявления DOCTYPE и значения атрибутов в кавычках — до того, как искать что-либо похожее на структуру тегов, чтобы их содержимое передавалось байт в байт, а не переинтерпретировалось как разметка.

Этот инструмент проверяет, что каждый тег правильно закрыт и правильно вложен — структурные правила, делающие документ «правильно сформированным» (well-formed) XML, — и сообщает конкретный несовпадающий или незакрытый тег, если проверка не проходит. Чего он не делает — так это не валидирует документ по DTD или XML Schema (XSD), что дополнительно проверило бы, соответствуют ли конкретные элементы, атрибуты и их значения правилам определённого типа документа: присутствует ли обязательный атрибут, появляется ли элемент в правильном контексте, соответствует ли значение ожидаемому типу данных. Это принципиально другая и более сложная проверка, требующая самого документа схемы в качестве дополнительных входных данных, — то, что форматтер общего назначения не может вывести из одного лишь XML.

Строгий XHTML является валидным XML и корректно форматируется здесь, но обычный реальный HTML — нет, по причинам, заложенным в самой спецификации HTML: пустые элементы вроде `<br>` и `<img>` никогда не закрываются и вообще не имеют закрывающего тега, у нескольких тегов закрывающие теги необязательны и автоматически подразумеваются браузерами, а браузеры допускают некорректную вложенность, которую строгий разбор XML сразу отклонил бы как ошибку. Строгий XML-форматтер, применённый к типичному HTML, выдавал бы ошибки на каждой корректной, совершенно обычной странице, и именно поэтому для HTML существует отдельный форматтер, построенный вокруг настоящего HTML-парсера, который понимает эти специфичные для HTML правила, а не рассматривает документ как строгий XML.

JSON заменил XML как выбор по умолчанию для новых веб-API, но огромная часть инфраструктуры была построена ещё до этого сдвига и до сих пор работает на XML: SOAP веб-сервисы, RSS- и Atom-фиды, SVG-изображения (сами по себе являющиеся XML), форматы документов Office внутри себя и длинный хвост корпоративных систем и форматов конфигурации, появившихся до популярности JSON. Каждому, кто интегрируется с одной из таких более старых или более формальных систем, всё ещё нужно читать, отлаживать и создавать правильно сформированный XML, и это ровно та аудитория, которой продолжает служить выделенный XML-форматтер, даже несмотря на то, что XML отступил на второй план в дизайне новых API.