В 105-ом выпуске мы подробно рассмотрели формат DTD: чем является, где применяется и какая польза. На самом деле, эта статья была умышленно сфабрикована для того, чтобы мы смогли идти дальше по валидации разных языков программирования.
Сегодня мы постараемся погрузиться в валидацию до боли знакомых нам языков разметки: XML и XHTML. На первый взгляд, они такие похожие и должны рассматриваться как одно целое, но на самом деле они довольно разные и для них следует писать совершенно разные валидаторы. Можно даже выразиться следующим образом: проверка XHTML на XML-валидаторе будет недостаточной, а XML на XHTML-валидаторе — избыточной, и обе проверки покажут, что документ невалиден.
Общие шаги
Перед тем как переходить к частному, рассмотрим общие шаги на пути к становлению валидации. Для того, чтобы произвести валидацию содержимого, его сначала нужно получить. Источник (то, что мы должны проверить на соответствие набору определённых правил) может быть совершенно непредсказуемым:
- Файл;
- Строка;
- Удалённый источник.
Мы абстрагируемся от указанных выше источников, ведь на самом деле нам не так уж и важно, откуда мы получаем данные для валидации: все они в конечном итоге предстают в виде строки. После того, как мы получили строку, нам нужно её обработать таким образом, чтобы получить элементы, с которыми мы можем работать на том языке программирования, на котором мы программируем. Для начала мы должны определиться, в какие сущности мы можем превратить входные данные. Вспоминаем, что основной единицей в XML/XHTML является элемент. От него и будем отталкиваться. Помимо элемента, нам нужен контейнер элементов, который мы будем называть документом.
Каждый XML/XHTML-документ состоит из набора элементов, причём всегда есть корневой элемент, содержащий в себе все остальные элементы. Постойте! Но ведь это же обычное дерево! Да-да, всё правильно: мы видим перед собой дерево элементов. Мы пришли к достаточно важному выводу: любой XML-документ (и документ на любом XML-подобном языке) можно представить в виде дерева. После, с этим деревом мы можем выполнять самый разный набор операций: сравнение, удаление, перестановка, траверсинг (операция прохода по всем узлам дерева) и другие.
Как проверяется XML
Проверка XML несравненно проще проверки XHTML: нам необходимо лишь удостовериться в выполнении нескольких требований, что можно сделать совершенно спокойно, учитывая то, что у нас есть дерево элементов. Систематизируем необходимые правила:
- Первый элемент в документе — это всегда декларация заголовка XML вида , где […] — атрибуты заголовка XML;
- Все элементы должны быть названы верным образом и не должны содержать посторонних символов (пробелов, к примеру);
- Все атрибуты должны быть записаны в правильной форме (проверяется достаточно просто, тем же регулярным выражением);
- Документ должен содержать только один корневой элемент;
- Вложенность элементов должна быть соблюдена (проверка данного утверждения достигается за счёт использования стека элементов, с помощью которого мы проверяем соответствия открывающих и закрывающих элементов);
Примечание: валидатор не должен исправлять ошибки в XML-документах, так как это не входит в его компетенцию.
Если все вышеуказанные правила соблюдаются, то документ считается валидным XML-документом. В противном случае — документ содержит ошибки, список которых валидатор может вывести пользователю для ознакомления и исправления.
XHTML: лёгкие Интернета
Проверка XHTML основывается на валидации XML. Сначала мы должны удостовериться в том, что документ является валидным с точки зрения XML (то есть соблюдена вложенность тегов, правильно оформлены элементы и их атрибуты, и другие), и уже потом накладывать дополнительные правила. Если документ не является валидным с точки зрения XML, то он заведомо не является валидным и с точки зрения XHTML.
Чтобы применять какие-либо правила XHTML к документу, сначала нужно эти правила описать таким образом, чтобы их было легко получить и как трафарет наложить на документ. Для валидации XHTML-документов правила могут храниться в виде нескольких форматов:
- DTD-документы;
- XML Schema;
- Relax NG.
Независимо от формата, производится следующий набор проверок:
- Проверка всех используемых элементов в документе на их наличие в XHTML (если элемент, указанный в документе, не существует, то выдаётся соответствующая ошибка);
- Проверка на наличие обязательных атрибутов у соответствующих элементов;
- Проверка типа содержимого некоторых атрибутов на соответствие тем типам, которые указаны в правилах;
- Тип содержимого элемента должен совпдадать с тем, который указан в правилах;
- Так как XHTML определяет классы элементов (блоковые и текстовые), то валидатор должен убедиться в том, что элементы одного класса (уровня) должны быть правильно вложены в элементы другого класса (уровня). Подобные закономерности также описываются в правилах.
После выполнения указанного набора правил можно говорить о том, является ли документ валидным или напротив: содержит какие-то ошибки, которые валидатор может указать пользователю.
Итоги
Логично было бы заметить, что отсутствует описание процесса обработки документов для их представления в виде дерева элементов (абстрактно или на конкретном языке программирования). Если таковой процесс интересен читателям, то он будет описан в отдельной статье, в противном случае будем двигаться дальше по намеченному вектору.