XSD — умный XML
XSD — это язык описания структуры XML документа. Его также называют XML Schema. При использовании XML Schema XML парсер может проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных.
Такой подход позволяет объектно-ориентированным языкам программирования легко создавать объекты в памяти, что, несомненно, удобнее, чем разбирать XML как обычный текстовый файл.
Кроме того, XSD расширяем, и позволяет подключать уже готовые словари для описания типовых задач, например веб-сервисов, таких как SOAP.
Стоит также упомянуть о том, что в XSD есть встроенные средства документирования, что позволяет создавать самодостаточные документы, не требующие дополнительного описания.
Рассмотрим в качестве примера XSD документ, описывающий часть структуры аккаунта на хабре.
Текст XSD схемы и XML документ, соответствующий этой схеме я не стал включать в статью из-за их размера.
Первая строчка схемы указывает, что документ является XML документом и использует кодировку UTF-8.
xs:annotation >
xs:documentation > Главный элемент схемы. Описывает пользователя хабра xs:documentation >
xs:annotation >
Тег описывает «сложный» тип данных user_name. При желании его можно вынести как отдельный тип данных, по аналогии с contact_info. Для этого, нужно блок перенести в и указать атрибут name, а элементу задать атрибут type.
Элементы user_name, first_name, last_name имеют строковый тип и описывают пользователя, имя и фамилию владельца аккаунта.
Элемент date_of_birth имеет тип данных «дата» и описывает дату рождения.
Дату регистрации описывает register_date, имеющий собственный тип данных customDateTime. Значение этого тега будет задаваться с помощью атрибута value. На это указывают строки.
xs:simpleType >
xs:restriction base =»xs:string» >
xs:length value =»19″/>
xs:pattern value =»1519-12-29 17:23:48″/>
xs:restriction >
xs:simpleType >
Элементы contact_info и blog — массивы, на это указывает атрибут maxOccurs=«unbounded».
Тег определяет то, что вложенным элементом будет один из элементов ICQ или linkedin.
Дополнительно о XSD схемах можно почитать Wikipedia и W3C. Для создания макета была использована программа Altova XMLSpy.
XSD: частичная валидация
XSD — это язык описания структуры XML документа. Его также называют XML Schema. При использовании XML Schema XML-парсер может проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных. Многие так или иначе сталкивались с процедурой полной валидации, обеспечивающей соответствие документа заданной схеме или сообщающей о возможных ошибках. В данной статье речь пойдет о частичной валидации, кроме вышеописанного, позволяющей конструировать валидные документы «на лету». Мы разберемся, какие возможности может предоставить такой подход и способы его реализации.
Основная цель
Зачем вообще может понадобиться конструировать документ, обладающий заданными свойствами, и какими свойствами мы можем управлять? На первый вопрос ответ практически очевиден; большинство документов не являются просто текстом, а наделены некоторой семантикой. XML решает вопрос синтаксического представления, а схема – частично решает вопрос семантического значения. Благодаря соответствию документа схеме, можно выполнять над ним набор предопределенных действий, допустимых для целого класса валидных документов, будь то представление в другом формате, экспорт значимой части информации для конкретной задачи, импорт новой информации с учетом глобальных ограничений. Наиболее часто применяемый механизм в таком случае – это XSLT преобразование, смысл которого можно проиллюстрировать следующей диаграммой:
Часто возникает желание модифицировать документ, уже отвечающий выбранной схеме, таким образом, чтобы он не потерял валидность. Здесь речь идет и о автоматических модификациях, например добавление веб-агентами (агрегаторами) информации в документ или модифицирующие запросы в XML-базу данных, так и о ручной модификации, скажем, в визуальном XML-редакторе. Операция полной валидации для больших документов может занимать существенное время, десятки секунд и более, что в целом препятствует использованию подхода «атомарное изменение – проверка – отказ/разрешение». А для визуальных редакторов хотелось бы еще больше – иметь возможность не только проверить атомарное действие, а предложить все допустимые по схеме варианты модификации конкретного узла. Однако, хорошие XML-редакторы умеют это делать, и мы попробуем разобраться каким образом у них это получается.
Необходимая информация о XML схеме
Правило Unique Particle Attribution (однозначность определения частиц) требует, чтобы каждый элемент документа однозначно соответствовал ровно одной частице xsd:element или xsd:any в модели содержимого родительского элемента [2].
Вообще говоря, правило Unique Particle Attribution (UPA) не является жестким требованием к структуре XML схем, а только крайне желательной рекомендацией и часть используемых схем ему не соответствует. Рассмотрим простейший пример, иллюстрирующий нарушение правила однозначности определения частиц.
Построение валидатора
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 без вызова внешнего валидатора.
Шаблоны проектирования XSD
В жизни каждого аналитика и программиста наступает такой день, когда он узнает о существовании шаблонов (паттернов) проектирования XML-схем и его жизнь меняется. Для меня, например, с этого знания началось постижение красоты проектирования.
Сегодня хочу поговорить о том, какие есть шаблоны проектирования XSD, о преимуществах и недостатках каждого, и почему мы для своих задач выбрали «Райский сад».
Для примера возьмем следующий XML-документ в качестве источника данных.
И посмотрим, как можно описать одну и ту же структуру XML-документа разными способами.
В основе разделения на шаблоны лежит принцип определения глобальных элементов и/или типов данных внутри XSD.
Матрешка (Russian Doll)
Суть шаблона в том, что схема является зеркалом описываемого ею XML-документа: если сложные элементы содержат внутри себя другие сложные элементы, а те в свою очередь содержат простые, то и в XSD описания таких элементов будут вложены друг в друга. Название шаблон получил в честь известной во всем мире нашей куклы-матрешки, по аналогии с тем, как дочерние элементы в шаблоне инкапсулируются в родительские.
Схема, описывающая структуру нашего файла-источника с использованием шаблона «Матрешка», выглядит так:
Салями (Salami Slice)
Суть шаблона в том, что описываемый XML-документ разделяется на составные элементы, каждый из которых описывается в XSD как глобальный. Затем описанные элементы соединяются воедино.
Схема, описывающая структуру файла-источника с использованием шаблона «Салями», выглядит так:
Венецианские жалюзи (Venetian Blind)
Суть шаблона в том, что описываемый XML-документ разделяется на составные типы, каждый из которых описывается в XSD как глобальный. Затем объявляется корневой элемент, соответствующий глобальному типу, соединяющему схему воедино.
Схема, описывающая структуру файла-источника с использованием шаблона «Венецианские жалюзи», выглядит так:
Райский сад (Garden of Eden)
«Райский сад» хорош тем, что определяет каждый элемент и составной тип данных как глобальный. Это позволяет ссылаться на любой тип или элемент в пределах одного XSD или из любой другой XSD и даже из WSDL. Только так можно полностью контролировать семантику и типов и элементов.
Схема, описывающая структуру файла-источника с использованием шаблона «Райский сад», выглядит так:
Выбор шаблона
Часто при выборе шаблона проектирования приходится искать баланс между возможностью повторно использовать компоненты схемы и глубиной взаимосвязи между компонентами. На рисунке показан потенциал каждого из шаблонов в разрезе этих двух аспектов.
Те схемы, в которых хорошо поддерживается повторное использование компонентов, с другой стороны имеют сильные взаимосвязи между компонентами. При необходимости что-то поменять в такой схеме разработчик схемы может столкнуться с тем, что менять придется много связанных элементов и/или типов. Такими схемами впоследствии трудно управлять.
Нам в проекте важнее всего было повторное использование типов и элементов схемы и во вторую очередь тотальный семантический контроль имен. Выбор шаблона был очевиден – Райский сад.
Небольшое лирическое отступление. Самым интересным применением шаблонов проектирования XML-схем на моей памяти был и остается гипноз аудитории. Один наш титулованный аналитик любит брать инициативу в свои руки через рассказ на эту тему. Засекала время, через 5 минут взгляд слушателей тускнеет, и они уходят куда-то далеко в себя. На «Райском саде» сознание большинства отключается.
И в заключении хочу добавить, что миксы шаблонов тоже возможны, мы с ними встречались.
Файл формата xsd: чем открыть, описание, особенности
XSD файлы часто используются вкупе с XML документами. В них представлены описания XML файла и правил.
XSD файлы часто используются вкупе с XML документами. В них представлены описания XML файла и правила, которым он подчиняется. У пользователей часто встает вопрос, чем открыть XSD. Для просмотра подойдут базовые утилиты, предустановленные на ПК, а вот для редактирования понадобится дополнительное ПО.
Общее описание формата xsd
Расширение «.xsd» – аббревиатура от XML Schema Definition. Главная задача файлов с таким расширением – описать XML. В них могут содержаться описания структуры, отдельных элементов, атрибутов. Информацию содержит текст, изложенный языком описания XML Schema. На этом языке создают программное обеспечение для работы с XML. В «.xsd» могут быть интегрированы элементы других словарей, не только XML Schema.
История возникновения
Впервые формат был введен в эксплуатацию в 2001 году. Его порекомендовал Консорциум Всемирной паутины. Эта организация внедряет технологические стандарты интернета. Цель Консорциума – достичь совместимости файлов и оборудования производителей из разных стран.
Стартовая разработка языка XML Schema 1.0, применяемого в расширении «.xsd», использовалась на протяжении 11 лет. 5 апреля 2012 года Консорциум одобрил введение новой – 1.1.
Как и чем открыть файл xsd расширения
Можно выбрать из трех вариантов, чем открыть файл XSD. Просматривать содержимое документа можно даже без ПК, используя опции браузера.
Онлайн
Для просмотра онлайн используется браузер. Подойдет как ПК, так и мобильный браузер.
XSD схема – чем открыть онлайн:
Чтобы просмотреть содержимое, в строку поиска вбивают путь к файлу: «file:///D:/document.xsd». После «file:///» указывается путь на выбранном устройстве, а также название.
Главный недостаток онлайн-просмотра формата – невозможность вносить изменения в структуру.
На компьютере
При использовании установленных на ПК программ опций при работе с XML Schema Definition больше. Можно не только узнать содержимое, но и отредактировать текст.
Если постоянно работать с форматом не предстоит, для управления такими документами используют текстовые редакторы. Подойдут следующие программы:
Принципиальных отличий в ПО нет. Microsoft Word удобнее с точки зрения редактирования, а WordPad тяжелее в освоении. Однако функционал программ при работе с данным форматом не меняется.
Самое простое ПО для просмотра формата – Блокнот. Для просмотра и редактирования в текстовом редакторе файл открывают командой «Открыть с помощью. », затем выбирают из списка программ нужный редактор. Также можно открыть файл через саму программу, выбрав функцию «Открыть» и указав путь к элементу.
Если с XML Schema Definition работают профессионально, то для просмотра и редактирования применяют более серьезные программы. Устанавливаются XML-редакторы, к которым относятся:
Профессионалы предпочитают вторую программу. Она подходит для работы на Windows, Linux, Microsoft и позволяет не только видоизменять, но и создавать файлы рассматриваемого формата. Для редактирования используется многофункциональная таблица.
Какие еще могут быть проблемы с xsd файлом
Даже если известно, что такое формат xsd, чем открыть файл такого типа, иногда возникают дополнительные проблемы. Главная сложность заключается в том, что бывает два варианта XML Schema Definition файлов. Первый – текстовые, в которых содержатся команды и описания. Их открывают при помощи приведенных выше способов. Но разработан и второй, менее распространенный тип – схемы для вышивки крестиком. Это изображения, а не текст.
Внешне файлы двух типов ничем не отличаются, у них одинаковое расширение. Если при попытке открыть документ онлайн или при помощи текстового редактора выдается ошибка, значит, перед пользователем изображение. Его открывают только одним способом – при помощи программы Pattern Maker For Cross Stitch, специально заточенной под схемы для вышивки.
Утилиту устанавливают на ПК. Программу для открытия xsd можно скачать бесплатно и с русским переводом. В Pattern Maker For Cross Stitch доступен не только просмотр xsd схемы, но и редактирование, и создание собственных файлов.
Разобраться с форматом не сложно. Даже новичок сможет с первого раза открыть файл при помощи предустановленного на ПК текстового редактора или «Блокнота».
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Если вы тестируете API, то должны знать про два основных формата передачи данных:
Сегодня я расскажу вам про XML. В списке доп литературы будет ссылка на книгу по XML, у меня нет цели ее дублировать, но я расскажу про этот формат тем, кто XML еще в глаза не видел. А дальше уже гуглим сами ))
XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.
Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!
Так что давайте разберемся, как он выглядит, как его читать, и как ломать! Да-да, а куда же без этого? Надо ведь выяснить, как отреагирует система на кривой формат присланных данных.
Содержание
Как устроен XML
Возьмем пример из документации подсказок Дадаты по ФИО:
И разберемся, что означает эта запись.
Ой, ну ладно, подловили! Не всегда. Бывают еще пустые элементы, у них один тег и открывающий, и закрывающий одновременно. Но об этом чуть позже!
С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается». Это как дорожные знаки:
— На въезде в город написано его название: Москва
— На выезде написано то же самое название, но перечеркнутое: Москва*
* Пример с дорожными знаками я когда-то давно прочитала в статье Яндекса, только ссылку уже не помню. А пример отличный!
Корневой элемент
В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. В случае REST API документ — это запрос, который отправляет система. Или ответ, который она получает.
Чтобы обозначить этот запрос, нам нужен корневой элемент. В подсказках корневой элемент — «req».
Он мог бы называться по другому:
Да как угодно. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа — сам запрос. Те параметры, которые мы передаем внешней системе. Разумеется, они тоже будут в тегах, но уже в обычных, а не корневых.
Значение элемента
Значение элемента хранится между открывающим и закрывающим тегами. Это может быть число, строка, или даже вложенные теги!
Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.
Внутри — значение запроса.
Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):
Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.
Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».
Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.
Откройте консоль разработчика через f12, вкладку Network, и посмотрите, какой запрос отправляется на сервер. Там будет значение count = 7.
См также:
Но оба значения идут без кавычек. В XML нам нет нужды брать строковое значение в кавычки (а вот в JSON это сделать придется).
Атрибуты элемента
У элемента могут быть атрибуты — один или несколько. Их мы указываем внутри отрывающегося тега после названия тега через пробел в виде
название_атрибута = «значение атрибута»
attr1=“value 1” attr2=“value 2” >Виктор Иван
Зачем это нужно? Из атрибутов принимающая API-запрос система понимает, что такое ей вообще пришло.
Например, мы делаем поиск по системе, ищем клиентов с именем Олег. Отправляем простой запрос:
А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:
Давайте разберем эту запись. У нас есть основной элемент party.
У него есть 3 атрибута:
Внутри party есть элементы field.
У элементов field есть атрибут name. Значение атрибута — название поля: имя, дата рождения, тип или номер телефона. Так мы понимаем, что скрывается под конкретным field.
Это удобно с точки зрения поддержки, когда у вас коробочный продукт и 10+ заказчиков. У каждого заказчика будет свой набор полей: у кого-то в системе есть ИНН, у кого-то нету, одному важна дата рождения, другому нет, и т.д.
Но, несмотря на разницу моделей, у всех заказчиков будет одна XSD-схема (которая описывает запрос и ответ):
— есть элемент party;
— у него есть элементы field;
— у каждого элемента field есть атрибут name, в котором хранится название поля.
А вот конкретные названия полей уже можно не описывать в XSD. Их уже «смотрите в ТЗ». Конечно, когда заказчик один или вы делаете ПО для себя или «вообще для всех», удобнее использовать именованные поля — то есть «говорящие» теги. Какие плюшки у этого подхода:
— При чтении XSD сразу видны реальные поля. ТЗ может устареть, а код будет актуален.
— Запрос легко дернуть вручную в SOAP Ui — он сразу создаст все нужные поля, нужно только значениями заполнить. Это удобно тестировщику + заказчик иногда так тестирует, ему тоже хорошо.
В общем, любой подход имеет право на существование. Надо смотреть по проекту, что будет удобнее именно вам. У меня в примере неговорящие названия элементов — все как один будут field. А вот по атрибутам уже можно понять, что это такое.
У элемента attribute есть атрибуты:
Такая вот XML-ка получилась. Причем упрощенная. В реальных системах, где хранятся физ лица, данных сильно больше: штук 20 полей самого физ лица, несколько адресов, телефонов, емейл-адресов…
Но прочитать даже огромную XML не составит труда, если вы знаете, что где. И если она отформатирована — вложенные элементы сдвинуты вправо, остальные на одном уровне. Без форматирования будет тяжеловато…
А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.
XML пролог
Иногда вверху XML документа можно увидеть что-то похожее:
Эта строка называется XML прологом. Она показывает версию XML, который используется в документе, а также кодировку. Пролог необязателен, если его нет — это ок. Но если он есть, то это должна быть первая строка XML документа.
UTF-8 — кодировка XML документов по умолчанию.
XSD-схема
XSD (XML Schema Definition) — это описание вашего XML. Как он должен выглядеть, что в нем должно быть? Это ТЗ, написанное на языке машины — ведь схему мы пишем… Тоже в формате XML! Получается XML, который описывает другой XML.
Фишка в том, что проверку по схеме можно делегировать машине. И разработчику даже не надо расписывать каждую проверку. Достаточно сказать «вот схема, проверяй по ней».
Если мы создаем SOAP-метод, то указываем в схеме:
Теперь, когда к нам приходит какой-то запрос, он сперва проверяется на корректность по схеме. Если запрос правильный, запускаем метод, отрабатываем бизнес-логику. А она может быть сложной и ресурсоемкой! Например, сделать выборку из многомиллионной базы. Или провести с десяток проверок по разным таблицам базы данных…
Поэтому зачем запускать сложную процедуру, если запрос заведом «плохой»? И выдавать ошибку через 5 минут, а не сразу? Валидация по схеме помогает быстро отсеять явно невалидные запросы, не нагружая систему.
Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!
А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?
Да-да, в идеале у нас есть подробное ТЗ, где всё хорошо описано. Но увы и ах, такое есть не всегда. Иногда ТЗ просто нет, а иногда оно устарело. А вот схема не устареет, потому что обновляется при обновлении кода. И она как раз помогает понять, как запрос должен выглядеть.
Итого, как используется схема при разработке SOAP API:
А теперь давайте посмотрим, как схема может выглядеть! Возьмем для примера метод doRegister в Users. Чтобы отправить запрос, мы должны передать email, name и password. Есть куча способов написать запрос правильно и неправильно: