Как проверить xml по xsd схеме

Name already in use

xml-guide / docs / source / xsd.rst

Go to file T
Go to line L
Copy path
Copy permalink

Open with Desktop
View raw
Copy raw contents Copy raw contents

Copy raw contents

V. Проверка XML-файла по XSD-схеме

В данном разделе описаны способы проверки XML-файла по XSD-схеме. Сделать это можно разными способами, существует много программ для этих целей. По XSD-схеме, например, проверяет программа Tester, но она только показывает ошибки и не дает их исправить. Для большего удобства лучше использовать специализированные редакторы такие, как XMLPad или MS Visual Studio.

Проверять файл по XSD-схеме целесообрано в исключительных случаях, например, если скрипт xml-healer.py не справился с исправлением файла. Подробнее в главе :ref:`xml-healer` .

MS Visual Studio является спецаилизированным инструментом для программистов, обладающим огромным функционалом. Работа с XML и автоматическая проверка по XSD — лишь одна из множества функций среды разработки. MS Visual Studio 15 можно скачать бесплатно с официального сайта: https://www.visualstudio.com/ru-ru/products/visual-studio-community-vs.

XMLPad — многофункциональный специализированный XML редактор. XMLPad обладает богатым функционалом, поддерживает XPath, возможность удалять целые блоки тегов, смену кодировок, проверку валидности и т.д. XMLPad доступен для бесплатного использования на сайте: http://xmlpad-mobile.com.

XMLPad уступает по удобству и возможностям MS Visual Studio, но если вы не являетесь программистом и у вас не установлена MS Visual Studio, лучше воспользоваться XMLPad.

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

Проверка по XSD-схеме в XMLPad

Откройте XML-файл, который требуется проверить в XMLPad File > Open.

Чтобы проверить файл по заданной XSD-схеме, его надо с ней ассоциировать. Перейдите в меню XML > Assign Schema/DTD.

Выберите W3C Schema и нажмите Browse, затем выберите XSD-схему для проверки.

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

Для удобства отображения можно включить переносы строк Edit > Word Wrap.

Проверка по XSD-схеме в MS Visual Studio

Откройте XML-файл, который требуется проверить в MS Visual Studio Файл > Открыть > Файл.

Чтобы проверить файл по заданной XSD-схеме, его надо с ней ассоциировать. Перейдите в меню XML-код > Схемы. .

Нажмите Добавить и выберите файл XSD-схемы.

Проверка на соответсвие XSD-схеме будет осуществляться автоматически на лету. Внизу в окне Списка ошибок будет отображаться список ошибок. При нажатии на ошибку, она будет подсвечена в редакторе.

Добавить окно Списка ошибок можно через Вид > Списка ошибок.

V. Проверка XML-файла по XSD-схеме¶

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

MS Visual Studio является спецаилизированным инструментом для программистов, обладающим огромным функционалом. Работа с XML и автоматическая проверка по XSD – лишь одна из множества функций среды разработки. MS Visual Studio 15 можно скачать бесплатно с официального сайта: https://www.visualstudio.com/ru-ru/products/visual-studio-community-vs.

Проверка по XSD-схеме в XMLPad¶

Откройте XML-файл, который требуется проверить в XMLPad File > Open.

Чтобы проверить файл по заданной XSD-схеме, его надо с ней ассоциировать. Перейдите в меню XML > Assign Schema/DTD.

Выберите W3C Schema и нажмите Browse, затем выберите XSD-схему для проверки.

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

Для удобства отображения можно включить переносы строк Edit > Word Wrap.

Проверка по XSD-схеме в MS Visual Studio¶

Откройте XML-файл, который требуется проверить в MS Visual Studio Файл > Открыть > Файл.

Чтобы проверить файл по заданной XSD-схеме, его надо с ней ассоциировать. Перейдите в меню XML-код > Схемы. .

Нажмите Добавить и выберите файл XSD-схемы.

Добавить окно Списка ошибок можно через Вид > Списка ошибок.

Validating XML file using external XSD Schema

W hen we generate an XML document, it is very important to validate it with the external schema XSD (XML Schema Definition). By validating it with the external schema, it helps in identifying the issues in the vocabulary of XML language with its associated grammar rules.

XSD helps us in figuring out all the Warnings, Errors, and Fatal Errors that are present in an XML Document. XSD helps us in creating our XML a well-formed and valid XML.

Well-Formed XML: An XML is said to be well-formed if all the opening tags and closing tags are correctly associated with each other and the closing tag must contain “</>”. Whether the tags are properly nested or not.
Valid XML: An XML is valid only if it satisfies all the conditions of being well-formed as well as it is associated with the external schema also.

For a detailed explanation of the XSD Schema, one can refer to this link.

Let’s see an example of a Well-formed and Valid XML

Now, let’s see an example of an Invalid XML

Above we can see that there are two different XMLs, in which one is a Valid XML and another one is an Invalid XML. The second XML is invalid because it violates the properties of XML. The opening tag and closing tag should be matching but in invalid XML opening and closing, tags are mismatching to each other.

If we want to write a Java Code for validating our XML to validate it against an external schema, we can proceed with the below code:

Here, in the above code, we have used few classes like- SchemaFactory, Schema, and Validator. Let’s study the need of these classes for XML Validation in detail-

javax.xml.validation

XMLConstants.W3C_XML_SCHEMA_NS_URI

javax.xml.validation

javax.xml.validation.Validator

Source

In the above code, we can see that object of SchemaFactory class is created from which we have created an object of class Schema that takes an XSD file as an argument and now it will generate some set of constraints that are needed to be validated with the XML file. After that Validator class will capture all the constraints of the Schema class by creating its object. The validate() method of the Validator class will take the XML file as input and it will be converted to StreamSource from the file provided.

When the above code is executed, during validation of the XML file, if any validation fails, it throws a SAXParseException. This exception helps us in locating the error in the XML file. This exception comes with some predefined methods that help us in locating the line in which error is coming. Some methods are like getLineNumber(), getColumnNumber(), and getMessage(). These methods give us at which line, at which column, and exactly what error is coming.

Below is the example, when any error is present in the XML file it prints in the below format.

Now, if there are many errors are present in XML, but our code is limited to catch only the first SAXParseException which is encountered first. To handle all exceptions together we need to do some modifications to our code.

To handle all the exceptions together, we need to do some modifications to our code. We need to create one XSDErrorHandler Class, that implements the ErrorHandler interface and catches all the exceptions at a single time of execution of the program.

Below is the code snippet :

By implementing XSDErrorHandler Class, it will capture all the exceptions into the String variable “Error” and it will classify them according to their type whether the exception which is encountered a Warning, Error or FatalError when the execution of the program is completed, it will store all the types of errors and will display at the end. All these types of errors are stored in the variable “Error”.

All the XSD errors captured in the List of String and can be displayed like this :

The above example is the list of all errors which are encountered during the validation of the XML file against an external Schema.

I hope this blog might be useful who are trying to validate an XML using external Schema and trying to capture all the XSD validation errors all at once instead of doing one by one.
Thank you!

XSD: частичная валидация

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

Основная цель

Зачем вообще может понадобиться конструировать документ, обладающий заданными свойствами, и какими свойствами мы можем управлять? На первый вопрос ответ практически очевиден; большинство документов не являются просто текстом, а наделены некоторой семантикой. XML решает вопрос синтаксического представления, а схема – частично решает вопрос семантического значения. Благодаря соответствию документа схеме, можно выполнять над ним набор предопределенных действий, допустимых для целого класса валидных документов, будь то представление в другом формате, экспорт значимой части информации для конкретной задачи, импорт новой информации с учетом глобальных ограничений. Наиболее часто применяемый механизм в таком случае – это XSLT преобразование, смысл которого можно проиллюстрировать следующей диаграммой:

Строго контролировать типизацию данных узлов и атрибутов;
Определять порядок следования узлов, следить за наличием обязательных узлов и атрибутов;
Требовать уникальность элементов в заданном контексте;
Создавать вариантные узлы, требующие наличия одних атрибутов или других, в зависимости от контекста;
Требовать выполнения определенного предиката на группе узлов или атрибутов.

Часто возникает желание модифицировать документ, уже отвечающий выбранной схеме, таким образом, чтобы он не потерял валидность. Здесь речь идет и о автоматических модификациях, например добавление веб-агентами (агрегаторами) информации в документ или модифицирующие запросы в XML-базу данных, так и о ручной модификации, скажем, в визуальном XML-редакторе. Операция полной валидации для больших документов может занимать существенное время, десятки секунд и более, что в целом препятствует использованию подхода «атомарное изменение – проверка – отказ/разрешение». А для визуальных редакторов хотелось бы еще больше – иметь возможность не только проверить атомарное действие, а предложить все допустимые по схеме варианты модификации конкретного узла. Однако, хорошие XML-редакторы умеют это делать, и мы попробуем разобраться каким образом у них это получается.

Необходимая информация о XML схеме

Шаблоны (any, anyType, anyAttribute), позволяющие использовать любой элемент, соответствующий заданному пространству имен;
Группы подстановки, определяющие набор типов, который может быть использован вместо конкретного описания типа;
Количество повторений, определяющее для каждого элемента минимальное и максимально допустимое количество его вхождений в тип (обобщение операторов Клини: «*», «+»).

Правило Unique Particle Attribution (однозначность определения частиц) требует, чтобы каждый элемент документа однозначно соответствовал ровно одной частице xsd:element или xsd:any в модели содержимого родительского элемента [2].

Вообще говоря, правило Unique Particle Attribution (UPA) не является жестким требованием к структуре XML схем, а только крайне желательной рекомендацией и часть используемых схем ему не соответствует. Рассмотрим простейший пример, иллюстрирующий нарушение правила однозначности определения частиц.

Определим схему следующим образом:
<xsd:element name=»root»>
<xsd:complexType>
<xsd:choice>
<xsd:element name=»e1″/>
<xsd:any namespace=»##any»/>
</xsd:choice>
</xsd:complexType>
</xsd:element>

Тогда XML документ, состоящий из одного элемента , доказывает нарушение правила однозначности; элемент может быть сопоставлен и ветке xsd:elment и xsd:any одновременно.
К счастью, большая часть готовых схем следуют правилу UPA. Дальнейшие рассуждения будут верны только в случае соответствия схемы правилу UPA, но в целом небольшими модификациями рассуждения можно добиться корректности и на не совместимых с UPA-схемах, за счет потери скорости.

Построение валидатора

ADD: создание подэлемента с типом x на позиции n;
REMOVE: удаление подэлемента, стоящего на позиции n;
MOVE: перенос элемента с позиции n на позицию m (хоть перенос и сводится к выполнению удаления и добавления элементов, но промежуточное состояние может нарушать валидность документа).

Частица:
• MinOccurs – минимальное число повторений терма (если 0, то терм становится опциональным);
• MaxOccurs – максимальное число повторений терма (допустима бесконечность – inf).
• Терм: описание элемента, шаблон, последовательность или выбор;
Описание элемента (typedef):
• Локальное имя;
• Имя пространства имен (может быть опущено, тогда элемент считается допустимым в любом пространстве имен);
• Группа подстановки – множество всех элементов, принимаемых в выражениях содержащих typedef;
Шаблон (any):
• Имя пространства имен, допустимого для элемента подстановки (может отсутствовать);
Последовательность (sequence):
• Последовательное перечисление допустимых частиц;
Выбор (choice):
• Множество допустимых частиц.

1. Построение недетерминированного конечного автомата (NFA) с заданным конечным состоянием S по заданной частице:
a. Установим начальное состояние n на S;

b. Если MaxOccurs частицы равен бесконечности (inf):
• Добавим новое промежуточное состояние t; получаемое из преобразования терма в NFA (случай 2); добавим эпсилон-ребра из t в n и из n в S:

c. Если MaxOccurs частицы – число m:
• Строим цепочку из (MaxOccurs-MinOccurs) преобразований терма, начиная из конечного состояния S, добавляя эпсилон-ребро из промежуточного состояния на каждом шаге в конечное состояние S;
Например, для MaxOccurs=4 и MinOccurs=2 получаем следующий автомат:

d. Достраиваем minOccurs копий преобразования терма от нового начального состояния n, до начального состояния, полученного на предыдущих шагах.

2. Построение недетерминированного конечного автомата с заданным принимающим состоянием S по заданному терму:
a. Если терм – шаблон (any):
• Создаем новое состояние b, и соединяем его с S ребром, помеченным типом терма, возвращаем b;

b. Если терм – описание элемента:
• Создаем новое состояние b, затем для каждого элемента группы подстановки создаем ребро из b в S, помеченное типом элемента и возвращаем b;

c. Если терм – выбор (choice):
• Создаем новое состояние b, для каждого элемента выбора создаем автомат (случай 1) и соединяем его эпсилон-ребрами с состоянием b и состоянием S. Возвращаем b;

d. Если терм – последовательность (sequence):
• Для каждого элемента выбора создаем автомат (случай 1) и соединяем полученные автоматы в обратном порядке, начиная с состояния S, и возвращаем первое состояние в цепочке;

Затем применим алгоритм Томпсона к полученным NFA [3], для построения детерминированных автоматов. Алгоритм Томпсона можно применить в тех же случаях, что и алгоритм построения детерминированного автомата Ахо и Ульмана, основанный на сворачивании одинаково помеченных не-эпсилон ребер [4]. Однако в ряде случаев по исходному автомату (созданному на шагах 1–2) алгоритм Ахо и Ульмана не сможет построить детерминированный автомат.

Их метки являются описаниями типов с одинаковыми локальными именами и названиями пространства имен;
Их метки – это названия шаблонов, с перекрывающимся областями;
Метка одного ребра – шаблон, другого – описание типа, оба лежат в одном пространстве имен, и описание типа входит в область шаблона.

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

Осталось решить последнюю задачу – выбор нужного конечного автомата при валидации операции над заданным элементом дерева. С этим нам поможет структура привязки типов валидации (PSVI, Post-Schema-Validation Infoset), порождаемая почти любым (например, MSXML или libxml) полным валидатором. Для любого элемента дерева она указывает на соответствующий ему тип в описании схемы – в точности тот, по которому мы порождали нужный автомат.

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

Операции MOVE и REMOVE не меняют тип операнда (поэтому не требуют изменения структуры PSVI), а операция ADD вместе с добавлением элемента x, потребует добавления в структуру PSVI типа x. Таким образом, вместе с изменением структуры мы меняем и информационное множество привязки типов валидации, решая задачу частичной валидации и поддерживая дерево PSVI без вызова внешнего валидатора.