XML-документ не соответствует XML-схеме: как найти и исправить ошибку

Сначала сохраните исходный файл и полный протокол

Сообщение «XML-документ не соответствует XML-схеме» — название класса проблем, а не готовый диагноз. Не начинайте с массовой замены символов. Сохраните копию файла, полный текст ошибки, выбранный тип документа и сведения о схеме, по которой выполнялась проверка.

Для внутренней работы заведите короткую карточку: где проверяли, какая версия файла отправлена, что именно не прошло и где находится проблемное значение. Номер строки полезен, но его недостаточно: после форматирования документа строки могут сместиться. Добавляйте название поля или путь элемента, если валидатор его показывает.

Отделите ошибку чтения XML от ошибки XSD

В спецификациях W3C различаются корректность XML как разметки и соответствие схеме. В первом случае файл может не разбираться из-за оборванного элемента, некорректного символа или кодировки. Во втором XML читается, но его структура либо значения не отвечают выбранной XSD.

Практический порядок такой: сначала добейтесь чтения файла, затем проверяйте соответствие нужной схеме. Если программа сообщает, что не может загрузить саму XSD или её зависимость, это ещё не доказывает дефект документа. Проверьте комплект схем и настройки проверяющего средства.

Проверьте тип документа и редакцию схемы

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

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

Читайте сообщение как подсказку о конкретном ограничении

Текст ошибки зависит от программы. Используйте таблицу для выбора направления проверки, а окончательное решение принимайте по описанию элемента и действительной схеме. Исправляйте одну причину за раз — так проще понять, какие сообщения были её следствием.

Даты, числа и справочники: исправляйте представление, сохраняя смысл

По правилам XML Schema Datatypes значения имеют определённые типы. Например, для xs:decimal десятичный разделитель — точка, а обычная запись даты xs:date имеет вид 2026-11-03. Это примеры типов XSD, не универсальное требование к любому текстовому полю: конкретная схема может задавать дополнительные ограничения.

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

Пусто, ноль и «не применяется» — разные ответы

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

Аналогично с обязательным участником: заполнение поля названием исполнителя только потому, что неизвестен заказчик, делает файл внешне полноценным и содержательно неверным. После каждого исправления задайте два вопроса: перестал ли валидатор ругаться и осталось ли значение правдивым?

Что делать с пространствами имён и порядком элементов

W3C Namespaces связывает имена элементов с пространствами имён. Поэтому одинаково написанный тег в другом namespace может иметь другое значение для проверки. А схема с заданной последовательностью элементов способна отклонить файл с правильными полями, размещёнными в неправильном порядке.

Такие ошибки часто удобнее исправлять повторным экспортом из подходящего редактора, чем ручным переносом тегов. Если проблема появилась после обновления программы, передайте разработчику обезличенное минимальное воспроизведение, версию схемы и протокол. Не отправляйте весь проект, когда достаточно описания одного сбойного поля.

Повторная проверка и выпуск исправленного документа

После исправления запускайте проверку всего документа: локальная правка может изменить обязательность соседних полей или выбор блока. Затем сверяйте затронутые сведения с исходником. Если изменился подписанный файл, подготовьте подпись для новой версии по требованиям принимающей системы.

Сохраните итоговый протокол вместе с точной версией XML. Успешная XSD-проверка закрывает вопрос структуры в пределах этой проверки; она не подтверждает достоверность проектных решений, комплектность всего обращения или полномочия подписанта. Если при загрузке возникает другая ошибка, разбирайте её как отдельный этап, сохранив полный ответ системы.