А валидация ли?

25 сентября 2008 года, 21:43

Валидация — как много в этом слове. Или же оно ни о чём не говорит и ничего не объясняет? Я думаю, что Web-инженеры, а особенно работники передовой (front-end), не раз пользовались валидацией от W3C, однако представляют ли они, что делает эта система и как она это делает? На все эти вопросы мы постараемся найти ответы.

Системы валидации

Такие системы сейчас используются повсеместно в интернете и прикладном программном обеспечении. Когда мы говорим слово «валидатор», мы, обычно, подразумеваем лишь валидатор от консорциума, однако валидатор — это любое программное обеспечение, которое проверяет правильность документа в конкретном контексте. Под контекстом подразумеваются правила, которым должен соответствовать данный документ. Валидатор старается проверить, соответствует ли документ всем или части указанных правил. Если документ не соответствует набору правил, то он оповещает об этом пользователя (или автора документа), так как системы валидации — это информационные системы. В них, конечно, может быть встроена функциональность для исправления ошибок в документе, но такая практика встречается достаточно редко, да и использовать её можно далеко не всегда. Системы валидации направленны именно на информирование пользователя об ошибках в обрабатываемом документе, это достаточно важный факт. Данный факт также накладывает ограничения на реализацию системы валидации: последние должны учитывать синтаксические и грамматические особенности обрабатываемых документов, а также иметь гибкую систему оповещения об ошибках (группы ошибок, степень важности ошибок, детальные описания возникших ситуаций и даже способы их решения или ссылке на таковые).

Рассмотрим простой пример: пусть у нас существует гипотетическая система валидации, которая на входе получает два типа файлов: файл с данными, которые нужно проверить, и файл с правилами, которые нужно наложить, как кальку, на наши данные. Так выглядят наши правила:

#Запятые перед союзами ПЕРЕД "что" , "где", "однако" => ","; #Предложения должны начинаться с большой буквы ПОСЛЕ ".", "?", "!", "!..", "?.." => БОЛЬШАЯ_БУКВА(1); #Перед открывающей скобкой должен стоять пробел ПЕРЕД "(" => " ";

Коротко рассмотрим формат нашего файла с правилами: со знака «#» начинются комментарии (чтобы внести ясность для тех, кто редактирует правила), выражения записываются следующим образом:

положение вхождение[, вхождение2, ...] => условие;

Валидатор, работающий по этим правилам, проверяет соответствие входных данных некоторым правилам русского языка.

Теперь рассмотрим пример входных данных:

Кот Матроскин даже не подозревал о том где лежит сметана. Дядя Фёдор тщательно скрывал это. шарик постоянно смеялся над Матроскиным за его неосмотрительность.

После обработки данных на нашем валидаторе с применением вышеописанных правил, мы получим результат «Не соответствует правилам, не валиден». Действительно: даже на первый взгляд наш текст содержит пунктуационные ошибки и опечатки. Как система валидации может нам поведать об ошибках? Каждая система вправе выдавать результаты валидации особым образом, здесь нет жёстких рамок. Главное, чтобы можно было вообще понять: в чём заключается ошибка и как её исправить.

Давайте модифицируем наш формат правил для поддержки сообщений об ошибках:

положение вхождение[, вхождение2, ...] => условие => ошибка[, решение];

Далее, модифицируем наши правила для соответствия формату правил:

#Запятые перед союзами ПЕРЕД "что" , "где", "однако" => "," => "Нет запятых перед союзами в частях сложноподчинённого предложения"; #Предложения должны начинаться с большой буквы ПОСЛЕ ".", "?", "!", "!..", "?.." => БОЛЬШАЯ_БУКВА(1) => "Новое предложение должно начинаться с большой буквы"; #Перед открывающей скобкой должен стоять пробел ПЕРЕД "(" => " " => "Перед скобкой принята постановка знака пробела";

Нам, как разработчикам нашей системы валидации, теперь нужно определить формат вывода сообщений об ошибках. Сделаем его аскетичным, но оставим информативным:

номер_строки: сообщение_об_ошибке. \r\n

Тогда, для нашего документа вывод будет выглядеть следующим образом:

1: Нет запятых перед союзами в частях сложноподчинённого предложения 2: Новое предложение должно начинаться с большой буквы

Разумеется, в наш формат правил можно добавить уровень важности ошибки (к примеру, «предупреждение», «ошибка») и даже тип ошибки (в нашем случае это будет «синтаксическая» или «пунктуационная» ошибка). Такие данные, конечно, можно также включить в вывод пользователю, а он уже будет делать выводы и исправлять ошибки в собственном творении.

Я думаю, что весь наш небольшой эксперимент можно легко перенести на системы валидации для SGML (XML, HTML, XHTML) и, в целом, должно быть ясно, как вся мельница работает, поэтому обойдёмся без Дон Кихота.

Системы соответствия

Системы валидации не являются единственными системами, с помощью которых проверяются документы: помимо них существуют ещё и системы соответствия. Очень важно понимать разницу между данными системами, так как она не совсем очевидна на первый взгляд, но чуть позже мы её рассмотрим.

Как мы уже выяснили, система валидации должна быть способной к выявлению ошибок и оповещению о них. Конечно, это влечёт к наращиванию дополнительной функциональности для проведения операций по проверке на наличие ошибок, что иногда недопустимо или является крайне излишним. Именно поэтому и существуют системы соответсия. Их основной целью является не обнаружение ошибок, а проверка на их наличие в наборе данных. О подобном я говорил ещё в статье про semi-valid документы.

Системы соответствия также могут содержать определённый набор правил, но он минимизирован по сравнению с теми же системами валидации. Помимо этого, системы соответствия могут пропускать определённые ошибки на уровне синтаксиса конкретных документов, улавливая лишь форму документов. Так, системы соответствия XHTML могут определить, что перед нами правильный XML-документ, что атрибуты оформлены верно, элементы закрыты правильно, однако такая система никогда не сообщит: есть ли данный элемент или атрибут в XHTML или его там нет. Это и есть коренное отличие систем валидации от систем соответствия. Думаю, и без примеров всё достаточно прозрачно.

В заключение

Хочу сказать, что существуют определённые тонкости при проектировании валидаторов для разного рода целей. Так, валидаторы и системы соответствия для лингвистических целей отличаются от валидаторов структурированного текста (как XML) некоторыми особенностями в силу отличий на уровне исходных данных.

В следующих статья постараемся более плотно подойти к системам соответствия и валидации для семейства SGML-языков и XML-языков.

Мнения (3)

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

Я тоже знаю!

Для обращения к человеку используйте символ @, после которого следует имя того, к кому обращаетесь (пробелы заменяются на знак подчёркивания). Если вам интересно, можете подписаться на комментарии по RSS или по эл. почте. Ведите себя достойно, вы же не роботы, правда?

Вы можете использовать следующие XHTML-элементы в разметке комментария: strong, em, span[class=crossline], a[href=uri], code[type=язык], blockquote, ul и ol. В качестве языка кода может быть указан, например, javascript или css.