Ошибка при валидации xml документа что это

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

Прежде всего давайте разберемся в каких случаях необходима валидация сообщений.

1. Мы можем ничего не знать о клиенте нашего сервиса, соответственно нам необходимо проверить запросы, поступающие от данного клиента, перед тем как их обрабатывать.
2. Сообщения, поступающие от внешних сервисов, т.е. сервисов, которые мы не контролируем, должны подвергаться валидации.

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

Не обязательно осуществлять валидацию сообщений в следующих случаях:

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

В данной заметке мы рассмотрим некоторые приемы валидации сообщений, а так же способы обработки ошибок, возникающих при проверке некорректных сообщений.

Валидация сообщений по схеме

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

Существует два подхода при описании контрактов сервисов:

• строго-типизированный сервис;
• слабо-типизированный сервис.

Рассмотрим особенности валидации по схеме при использовании каждого из данных подходов.

Строго-типизированный сервис

При использовании данного подхода мы подробно определяем все ограничения на каждый компонент структуры данных. Пример для пластиковой карты:

В данном примере мы проверяем следующие условия:

• тип карты: Visa или MasterCard;
• номер: 16 цифр;
• месяц, до которого действует карта, от 1 до 12;
• год, до которого действует карта, от 2010 до 9999;
• код безопасности: 3 цифры.

Данный подход снижает масштабируемость, например, уже будет сложно добавить обработку карт American Express, т.к. такие карты имеют 15-значный номер и 4-х значный код безопасности. Так же каждый год придется обновлять ограничение на ExpiryYear, т.к. год должен находиться в будущем.

Слабо-типизированный сервис

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

Пример:

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

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

Так же к недостаткам можно отнести тот факт, что потребитель сервиса не может по данному описанию понять, какие данные являются корректными, т.е. грубо говоря, что от него хотят. Требуется дополнительное документирование параметров сервиса.

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

Несколько советов при реализации валидации по схеме:

• входящий документ нужно валидировать как можно раньше;
• валидацию исходящего документа желательно разместить непосредственно перед вызовом внешнего сервиса;
• если речь идет о валидации ответа от разрабатываемой системы, то нужно понимать, что если мы получили корректный входящий документ (а мы его валидировали) и у нас правильно реализована логика его обработки, то наш ответ так же должен быть корректным.

Использование Schematron для валидации

При использовании Schematron валидация осуществляется следующим образом: вводится ряд утверждений (assertions), если все они исполняются, то документ считается корректным. Утверждения вводятся с помощью XPath-выражений, что позволяет задавать условия, которые в принципе нельзя задать, используя схему, например:

• если тип карты — American Express, то длина номера — 15 символов, иначе — 16;
• если тип карты — American Exptess, то длина кода безопасности — 4 символа, иначе — 3;
• дата окончания действия карты (месяц и год) должна быть больше текущей (т.е. в будущем).

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

Пример: проверка того, что тип карты указан как Visa или MasterCard:

Рассмотрим составные части Schematron-файла.

Утверждения (assertions) задаются в элементах assert. Важный атрибут утверждения — test — определяет XPath-выражение, которое может вернуть true или false. Если тестовое выражение возвращает true, то утверждение считается имеющим силу (met). Если возвращается false, то фиксируется ошибка валидации и содержимое элемента assert возвращается в качестве сообщения о данной ошибке.

Правила (rules). Утверждения определяются внутри правил. Правило содержит атрибут context, который включает в себя XPath-выражение, выбирающее узлы из валидируемого документа, к которым будут применяться утверждения. Для каждого узла будут применены правила, описанные в соответствующем элементе rule.

Пример:

в результате обработки выражения /emb:updateCreditCard/cmn:creditCard будет возвращен один единственный узел:

к которому и будет применено правило.

Если для правила определено несколько утверждений и все они не верны, то будет возвращено сообщение об ошибке для каждого утверждения.

Можно использовать относительный контекст, например, мы хотим определить правило валидации кредитной карты, независимо от операции в которой карта используется. Для этого нужно определить правило с использованием XPath выражения, возвращающего creditCard независимо от операции, например так:

Паттерны (patterns). Правила определяются внутри паттерна. Каждый паттерн содержит одно или более связанных правил. Элемент pattern содержит единственный атрибут — name, задающий в свободной форме описание правил, содержащихся внутри паттерна.

Schematron применяет паттерны друг за другом, правила внутри каждого паттерна применяются так же поочередно друг за другом.

Пространства имен (namespaces). Пространства имен описываются с помощью элемента ns. Элемент ns содержит два атрибута: uri — урл, задающий пространство имен и prefix — соответствующий префикс. Используются аналогично атрибуту xmlns схемы.

<ns uri=«http:// rubiconred.com/obay/xsd/cmn» prefix=«cmn»/>

Затем можно в правилах и утверждениях использовать префикс cmn.

Схема (schema) — корневой элемент для Schematron, определен в пространестве имен http://www.ascc.net/xml/schematron.

Примеры

Валидация в зависимости от содержимого нескольких полей:

Правило можно переписать красивее — использовать возможности XPath при определении правил:

Можно использовать функции, появившиеся в XPath 2.0:

Валидация дат. Пример проверки того, что указанная дата больше текущей:

Проверка на присутствие элемента:

Проверка на присутствие элемента и, если он присутсвует, на исполнение каких-то правил:

Важно! Если для какого-то значения не описано правило, то данное значение всегда будет валидироваться как корректное. Если нужно ограничить набор возможных значений, то необходимо создать отдельное правило.

Пример возврата ошибки валидации с помощью Schematron:

Использование бизнес-правил для валидации

Одним из методов реализации валидации является определение правил валидации как бизнес-правил. Это позволяет определить правила валидации один раз и затем использовать в нескольких сервисах. В свою очередь правила могут быть выставлены как веб-сервис, что позволяет легко использовать их из ESB или BPEL-процессов. Сами правила могут быть реализованы, например с помощью Oracle Business Rules, а для выставления их в качестве веб-сервиса может использоваться BPEL-обертка или соответствуюшее Java API.

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

Возврат ошибок валидации из синхронного сервиса

Необходим механизм возврата информации об ошибках валидации потребителям сервиса, желательно с подробной информацией о том, какое именно поле сообщения некорректно.

Для синхронного сервиса механизм возврата основан на использовании SOAP Fault. SOAP Fault содержит 4 раздела:

1. faultcode: высокоуровневый указатель на причину ошибки. SOAP 1.1 определяет следующие faultcode:
   — VersionMistmatch,
   — MustUnderstand,
   — Client
   — Server.

   Если ошибка в содержимом сообщения, полученного от клиента, и клиент должен исправить данную ошибку, то необходимо вернуть Client.

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

SOAP Fault’ы добавляются как дополнительные элементы fault в определение операции (элемент operation) WSDL-файла. Элемент fault имеет два атрибута: name — задает код ошибки и message — содержит дополнительную информацию об ошибке и возвращается внутри элемента soap:detail.

Пример:

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

SOAP 1.1 допускает создание своих кодов ошибок реализуемое через т.н. dot-notation: client.invalidCreditCard в пространстве имен http://schemas.xmlsoap.org/soap/envelope/. Однако это ведет к колизиям и создает проблемы интероперабельности, следовательно не является совместимым с WS-I Basic Profile. Нужно избегать таких решений.

Вместо этого необходимо определять коды ошибок в своих собственных пространствах имен. Например, можно определить свой код ошибки invalidCreditCard в том же пространстве имен, что и сервис userManagement.

Важно: Хотя определение своих кодов ошибок в своих пространствах имен и является совместимым с WS-I Basic Profile, WS-I BP рекомендует использовать стандартные коды ошибок SOAP 1.1, а информацию о конкретной ошибке передавать в поле detail.

Возврат ошибок валидации из асинхронного сервиса

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

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

В большинстве случаев можно считать наименование операции эквивалентом кода ошибки, а содержимое соответствующего сообщения может использоваться для передачи подробной информации об ошибке (например fault string и detail). Пример определения сервиса обработки кредитной карточки как асинхронного:

Соображения о многоуровневой валидации

При валидации существуют потенциальные проблемы, связанные с производительностью (очевидно, что процесс валидации требует времени), поэтому нужно внимательно прослеживать цепочки вызовов. Например, если мы используем сервис для валидации кредитных карт, а операция по карточке у нас проходит через цепочку сервисов, использующих данный сервис валидации, то получится, что он будет вызван N раз, хотя достаточно было бы одного раза.

Так же нужно внимательно управлять распространением ошибок и откатом транзакций (компенсациями). Например, в BPEL-процессе из сервиса A вызываютя сервисы B и C. Сервис B отработал корректно, а при вызове сервиса С произошла ошибка. В данном случае необходимо откатить изменения, сделанные в сервисе В.

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

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

Ресурсы

Статья написана на основе содержимого главы 13 — Building Validation Into Services книги Oracle SOA Suite Developer Guide.

Понравилось сообщение — подпишитесь на блог и Twitter

XML (Extensible Markup Language) — это распространенный формат для хранения и передачи данных. Он используется во многих областях, включая веб-разработку, базы данных и приложения.

В процессе работы с XML-документами могут возникать ошибки, такие как «Ошибка валидации XML: элемент resident code не соответствует формату xsd». Это означает, что элемент resident code в документе не соответствует формату, определенному в соответствующем XSD-схеме.

XSD (XML Schema Definition) — это язык, который определяет различные типы данных и форматы, которые могут быть использованы в XML-документах. Если элемент в XML-документе не соответствует формату XSD-схемы, то валидация XML-документа завершится с ошибкой.

Для исправления ошибки «Ошибка валидации XML: элемент resident code не соответствует формату xsd» необходимо проанализировать указанный элемент и сравнить его формат с требованиями XSD-схемы. Если элемент не соответствует требованиям, то его необходимо исправить. В противном случае, можно изменить XSD-схему, чтобы поддерживать текущий формат элемента.

Ошибка валидации XML: элемент resident code не соответствует формату xsd — что это значит и как исправить?

Эта ошибка означает, что в вашем XML-файле элемент «resident code» не соответствует формату, указанному в соответствующем файле XSD (XML Schema Definition).

XSD — это файл, который определяет структуру и ограничения для XML-документа, чтобы убедиться, что он соответствует определенным требованиям и стандартам. Если элемент «resident code» не соответствует формату, определенному в соответствующем файле XSD, то это может привести к ошибке валидации.

Чтобы исправить эту ошибку, вам необходимо проверить соответствие элемента «resident code» формату, определенному в файле XSD, и исправить его соответственно. Также стоит проверить все другие элементы и атрибуты, чтобы убедиться, что они также соответствуют формату XSD.

Кроме того, вы можете использовать специальные инструменты для валидации XML-файлов, которые помогут вам быстро найти и исправить ошибки в файле. Например, онлайн-сервисы, такие как XML Validation Tool или XML Schema Validator, могут быть полезными инструментами для обнаружения ошибок в XML-файлах.

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

Что такое валидация XML и как она работает?

XML (Extensible Markup Language) – это язык разметки документов, используемый для представления структурированных данных. Верификация XML-документов с помощью схемы XSD (XML Schema Definition) – это процесс проверки документа на соответствие определенной схеме. Валидация XML связана с проверкой того, что документ соответствует определенной на высоком уровне точности спецификации.

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

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

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

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

Что означает ошибка «элемент resident code не соответствует формату xsd»?

Ошибка «элемент resident code не соответствует формату xsd» означает, что валидатор XML обнаружил несоответствие элемента resident code с требованиями XSD-схемы. Это может произойти, если элемент не соответствует типу данных, указанному в схеме или имеет неверный формат.

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

Исправление ошибки «элемент resident code не соответствует формату xsd» зависит от типа ошибки и ее причины. Если элемент имеет неверный формат, то его нужно изменить, чтобы он соответствовал XSD-схеме. Если же проблема в типе данных, то необходимо пересмотреть схему и изменить требования к элементу.

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

Как определить точное место ошибки?

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

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

Также можно воспользоваться специализированными инструментами для отображения структуры XML-документа, такими как XML-редакторы или инструменты отладки, которые помогут быстро найти в документе тот элемент, который вызвал ошибку.

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

Как правило, в случае ошибки валидации XML лучшим решением будет просмотреть стандарт схемы XSD и ее требования к документу. В большинстве случаев объяснения ошибки и информации о стандартах XSD достаточно для того, чтобы найти и исправить ошибку в документе.

Как исправить ошибку «элемент resident code не соответствует формату xsd»?

Ошибка «элемент resident code не соответствует формату xsd» может возникнуть при попытке валидации XML-документа, который содержит элементы, не соответствующие формату XSD. В данном случае, XSD — это язык описания структуры документа, который позволяет проверять соответствие документа заданной схеме.

Для исправления данной ошибки необходимо пересмотреть структуру XML-документа и проверить, соответствуют ли элементы в нем описанной схеме XSD. Если не соответствуют, необходимо либо изменить структуру документа, либо исправить схему XSD.

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

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

Какие еще причины могут вызвать ошибку валидации XML?

Ошибка валидации XML может возникнуть не только из-за несоответствия элементов заданному формату xsd, но и из-за следующих причин:

• Неправильный формат файла: XML-файл должен быть написан в правильном формате, иначе он не сможет пройти проверку на валидность;
• Нарушение правил структуры XML: любое нарушение структуры XML-файла, такое как отсутствие обязательных элементов, неверный порядок элементов, неправильно указанные атрибуты и т.д., может вызвать ошибку валидации;
• Изменение структуры xsd-файла: если xsd-схема изменяется, а XML-файлы остаются прежними, это может вызывать ошибку валидации;
• Ссылки на внешние ресурсы: если XML-файл содержит ссылки на внешние ресурсы, такие как DTD или другие xml-файлы, то возможны ошибки валидации, если эти ресурсы изменены или отсутствуют;
• Необходимость проверки начальных и конечных тегов: в xml-файле должна быть корректная последовательность начальных и конечных тегов. Если последовательность нарушена, то может возникнуть ошибка валидации.

Для исправления ошибок валидации XML-файла разработчики могут использовать различные инструменты и программы, которые позволяют проверить соответствие xml-файла заданному схематическому описанию xsd. Чтобы избежать ошибок валидации, следует внимательно проверять xml-файлы перед отправкой на сервер и следовать правилам структуры XML и xsd-схематических описаний.

Как бороться с ошибками валидации XML?

Прежде всего, необходимо понимать, что валидация XML — это процесс проверки соответствия документа XML определенному схематическому описанию (XSD).

Ошибки валидации могут возникать из-за несоответствия элементов и атрибутов документа определенным правилам формата XSD. Для того чтобы исправить ошибки валидации, необходимо просмотреть сообщения об ошибках и определить, в какой части документа они возникли.

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

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

Чтобы избежать ошибок валидации, следует строго соблюдать правила формата XSD при создании документа XML. Также рекомендуется использовать специализированные программы для проверки документов на соответствие правилам формата XSD.

В общем, для исправления ошибок валидации XML можно использовать следующие подходы: тщательный анализ сообщений об ошибках, внесение изменений в документ XML, приведение документа к формату XSD, соблюдение правил формата при создании документа.

Вопрос-ответ

Что такое ошибка валидации XML?

Ошибка валидации XML — это ошибка, которая возникает при проверке корректности XML-документа на соответствие схеме XSD. Если элемент XML-документа содержит данные, которые не соответствуют формату XSD, то появляется ошибка валидации.

Как исправить ошибку валидации «элемент resident code не соответствует формату xsd»?

Для исправления ошибки необходимо проверить соответствие данных элемента resident code формату XSD. Если данные не соответствуют формату XSD, то их необходимо изменить. Если формат XSD должен быть изменен, то необходимо изменить соответствующую схему XSD.

Как проверить соответствие данных формату XSD?

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

Что такое формат XSD?

Формат XSD (XML Schema Definition) — это язык для определения структуры XML-документов. Он определяет набор правил для структурирования данных в XML-документах и позволяет определять типы данных для элементов XML-документов.

Может ли ошибка валидации XML повлиять на работу программы?

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

Какие могут быть причины ошибки валидации XML?

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

   prog1Csww

19.07.22 — 09:47

   prog1Csww

1 — 19.07.22 — 09:50

   prog1Csww

2 — 20.07.22 — 01:33

Вверх.

   prog1Csww

3 — 20.07.22 — 07:20

   Ryzeman

4 — 20.07.22 — 07:27

Ну, вообще тебе английским по-белому писало ошибку что в (0) что сейчас. В (0) была проблема с <Контент> как раз то, что ты не написал. В теле ожидалась строка base64Binary, у тебя там были какие-то недопустимые символы. В (3) у тебя где-то в XML незакрытый элемент <p>. То есть он буквально тебе пишет, что открытие тега <p> должно сопровождаться его закрытием. Посмотреть это можно в любой удобной гляделке XML — в браузере или notepad++ с компонентой для XML, например. Не видя что ты там формируешь что-то тебе ещё посоветовать невозможно.

   Ryzeman

5 — 20.07.22 — 07:29

Вариант — у тебя где-то шифруется что то вроде <p или <p>, например, если ты код маркировки передаёшь — это возможно. Тогда надо символы < и > экранировать.

   prog1Csww

6 — 20.07.22 — 09:51

(4) <?xml version=»1.0″ encoding=»WINDOWS-1251″?>

<Файл ИдФайл=»ON_NSCHFDOPPR_2ZK-CUS-03223001038_2ZK-SUP-00019150656_20220715_37B62CBA-66A5-4722-A350-5AF49F97E98E» ВерсФорм=»5.01″ ВерсПрог=»12.2″>

    <СвУчДокОбор ИдОтпр=»2ZK-SUP-00019150656″ ИдПол=»2ZK-CUS-03223001038″>

        <СвОЭДОтпр НаимОрг=»Федеральное казначейство» ИННЮЛ=»7710568760″ ИдЭДО=»2ZK»/>

    </СвУчДокОбор>

    <Документ КНД=»1115131″ Функция=»СЧФДОП» ПоФактХЖ=»Документ об отгрузке товаров (выполнении работ), передаче имущественных прав (документ об оказании услуг)» НаимДокОпр=»Счет-фактура и документ об отгрузке товаров (выполнении работ), передаче имущественных прав (документ об оказании услуг)» ДатаИнфПр=»15.07.2022″ ВремИнфПр=»01.44.16″ НаимЭконСубСост=»ИВАНОВА ОЛЬГА ВЛАДИМИРОВНА» СоглСтрДопИнф=»0000.0000.0000″>

        <СвСчФакт НомерСчФ=»4″ ДатаСчФ=»20.07.2022″ КодОКВ=»643″>

            <СвПрод>

                <ИдСв>

                    <СвИП ИННФЛ=»123456789012″>

                        <ФИО Фамилия=»ИВАНОВА» Имя=»ОЛЬГА» Отчество=»ВЛАДИМИРОВНА»/>

                    </СвИП>

                </ИдСв>

                <Адрес>

                    <АдрРФ КодРегион=»99″ Город=»Г ИВАНОВО»/>

                </Адрес>

                <Контакт Тлф=»7 999 999 9999″ ЭлПочта=»hleb@mail.ru»/>

                <БанкРекв НомерСчета=»99999999999999999999″>

                    <СвБанк НаимБанк=»ПАО СБЕРБАНК» БИК=»999999999″ КорСчет=»99999999999999999999″/>

                </БанкРекв>

            </СвПрод>

            <СвПокуп ОКПО=»99999999″ ИнфДляУчаст=»0″ КраткНазв=»МБДОУ ДЕТСКИЙ САД»>

                <ИдСв>

                    <СвЮЛУч НаимОрг=»МУНИЦИПАЛЬНОЕ БЮДЖЕТНОЕ ДОШКОЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ДЕТСКИЙ САД» ИННЮЛ=»9999999999″ КПП=»999999999″/>

                </ИдСв>

                <Адрес>

                    <АдрРФ Индекс=»999999″ КодРегион=»99″ Город=»ГОРОД ИВАНОВО» Улица=»УЛИЦА ИВАНОВА» Дом=»ДОМ 9″/>

                </Адрес>

                <Контакт Тлф=»8 999 999 99 99″ ЭлПочта=»dou@yandex.ru»/>

                <БанкРекв НомерСчета=»99999999999999999999″>

                    <СвБанк НаимБанк=»УФК по Иваново» БИК=»999999999″ КорСчет=»99999999999999999999″/>

                </БанкРекв>

            </СвПокуп>

            <ДопСвФХЖ1 НаимОКВ=»Российский рубль»>

                <ИнфПродГосЗакКазн ДатаГосКонт=»14.06.2022″ НомерГосКонт=»999 999″/>

            </ДопСвФХЖ1>

            <ДокПодтвОтгр НаимДокОтгр=»Документ о приемке» НомДокОтгр=»2″ ДатаДокОтгр=»15.07.2022″/>

        </СвСчФакт>

        <ТаблСчФакт>

            <СведТов НомСтр=»1″ НаимТов=»Хлеб пшеничный» ОКЕИ_Тов=»166″ КолТов=»4.8″ ЦенаТов=»100.33″ СтТовБезНДС=»481.58″ НалСт=»без НДС» СтТовУчНал=»481.58″>

                <Акциз>

                    <БезАкциз>без акциза</БезАкциз>

                </Акциз>

                <СумНал>

                    <БезНДС>без НДС</БезНДС>

                </СумНал>

                <ДопСведТов ПрТовРаб=»1″ НаимЕдИзм=»Килограмм» КодТов=»10.71.11.110″/>

            </СведТов>

            <СведТов НомСтр=»2″ НаимТов=»Хлеб ржано-пшеничный» ОКЕИ_Тов=»166″ КолТов=»2.8″ ЦенаТов=»99″ СтТовБезНДС=»277.2″ НалСт=»без НДС» СтТовУчНал=»277.2″>

                <Акциз>

                    <БезАкциз>без акциза</БезАкциз>

                </Акциз>

                <СумНал>

                    <БезНДС>без НДС</БезНДС>

                </СумНал>

                <ДопСведТов ПрТовРаб=»1″ НаимЕдИзм=»Килограмм» КодТов=»10.71.11.110″/>

            </СведТов>

            <ВсегоОпл СтТовБезНДСВсего=»758.78″ СтТовУчНалВсего=»758.78″>

                <СумНалВсего>

                    <БезНДС>без НДС</БезНДС>

                </СумНалВсего>

            </ВсегоОпл>

        </ТаблСчФакт>

        <СвПродПер>

            <СвПер СодОпер=»Работы выполнены в полном объеме» ДатаПер=»04.07.2022″>

                <ОснПер НаимОсн=»Контракт» НомОсн=»999 9999″ ДатаОсн=»14.06.2022″ ДопСвОсн=»Реестровый номер в реестре контрактов: 9999999999999999999″/>

                <ТранГруз/>

            </СвПер>

        </СвПродПер>

        <Подписант ОблПолн=»5″ Статус=»4″ ОснПолн=»Должностные обязанности»>

            <ИП ИННФЛ=»123456789012″>

                <ФИО Фамилия=»ИВАНОВА» Имя=»ОЛЬГА» Отчество=»ВЛАДИМИРОВНА»/>

            </ИП>

        </Подписант>

    </Документ>

</Файл>

xml:

<?xml version="1.0" encoding="UTF-8"?>
<!--
To change this license header, choose License Headers in Project Properties.
To change this template file, choose Tools | Templates
and open the template in the editor.
-->

<!DOCTYPE file SYSTEM "ex2.xsd">

<file>
    <medical_record>
        <first_name>Иван</first_name>
        <last_name>Попов</last_name>
        <disease>Ветрянка</disease>
        <disease>Простуда</disease>
    </medical_record>

    <medical_record>
        <first_name>Алексей</first_name>
        <last_name>Иванов</last_name>
        <disease>Простуда</disease>
        <disease>Грип</disease>
        <disease>Астма</disease>
    </medical_record>
</file>

xsd:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
    <xs:element name="file">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="medical_record" maxOccurs="unbounded" minOccurs="0">
              <xs:complexType>
                <xs:sequence>
                  <xs:element type="xs:string" name="first_name"/>
                  <xs:element type="xs:string" name="last_name"/>
                  <xs:element type="xs:string" name="disease" maxOccurs="unbounded" minOccurs="0"/>
                </xs:sequence>
                <xs:attribute type="xs:string" name="reg-num" use="optional"/>
              </xs:complexType>
            </xs:element>
          </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

Ошибка:
The markup declarations contained or pointed to by the document type declaration must be well-formed. [3]
Ошибка возникает при валидации xml документа, при проверке xsd файла всё нормально. Ругается ошибка на третью строку xsd файла.