Как составить xml запрос

Если вы тестируете API, то должны знать про два основных формата передачи данных:

  • XML — используется в SOAP (всегда) и REST-запросах (реже);
  • JSON — используется в REST-запросах.

Сегодня я расскажу вам про XML.

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.

Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!

См также:
Что такое API — общее знакомство с API
Что такое JSON — второй популярный формат
Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

Так что давайте разберемся, как он выглядит, как его читать, и как ломать! Да-да, а куда же без этого? Надо ведь выяснить, как отреагирует система на кривой формат присланных данных.

Содержание

  • Как устроен XML
    • Теги
    • Корневой элемент
    • Значение элемента
    • Атрибуты элемента
    • XML пролог
    • XSD-схема
    • Практика: составляем свой запрос
  • Well Formed XML
    • 1. Есть корневой элемент
    • 2. У каждого элемента есть закрывающийся тег
    • 3. Теги регистрозависимы
    • 4. Правильная вложенность элементов
    • 5. Атрибуты оформлены в кавычках
  • Итого

Как устроен XML

Возьмем пример из документации подсказок Дадаты по ФИО:

<req>
<query>Виктор Иван</query>
<count>7</count>
</req>

И разберемся, что означает эта запись.

Теги

В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки:

<tag>

Текст внутри угловых скобок — название тега.
Тега всегда два:

  • Открывающий — текст внутри угловых скобок
    <tag>
  • Закрывающий — тот же текст (это важно!), но добавляется символ «/»
    </tag>

Ой, ну ладно, подловили! Не всегда. Бывают еще пустые элементы, у них один тег и открывающий, и закрывающий одновременно. Но об этом чуть позже!

С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается». Это как дорожные знаки:

— На въезде в город написано его название: Москва
— На выезде написано то же самое название, но перечеркнутое:

Москва

*

* Пример с дорожными знаками я когда-то давно прочитала в статье Яндекса, только ссылку уже не помню. А пример отличный!

Корневой элемент

В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. В случае REST API документ — это запрос, который отправляет система. Или ответ, который она получает.

Чтобы обозначить этот запрос, нам нужен корневой элемент. В подсказках корневой элемент — «req».

Он мог бы называться по другому:

<main>

<sugg>

Да как угодно. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа — сам запрос. Те параметры, которые мы передаем внешней системе. Разумеется, они тоже будут в тегах, но уже в обычных, а не корневых.

Значение элемента

Значение элемента хранится между открывающим и закрывающим тегами. Это может быть число, строка, или даже вложенные теги!

Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.

Внутри — значение запроса.

Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):

Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.

Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».

Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.

Откройте консоль разработчика через f12, вкладку Network, и посмотрите, какой запрос отправляется на сервер. Там будет значение count = 7.

См также:
Что тестировщику надо знать про панель разработчика — подробнее о том, как использовать консоль.

Обратите внимание:

  • Виктор Иван — строка
  • 7 — число

Но оба значения идут

без

кавычек. В XML нам нет нужды брать строковое значение в кавычки (а вот в JSON это сделать придется).

Атрибуты элемента

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

название_атрибута = «значение атрибута»

Например:

<query attr1=“value 1”>Виктор Иван</query>
<query attr1=“value 1” attr2=“value 2”>Виктор Иван</query>

Зачем это нужно? Из атрибутов принимающая API-запрос система понимает, что такое ей вообще пришло.

Например, мы делаем поиск по системе, ищем клиентов с именем Олег. Отправляем простой запрос:

<query>Олег</query>

А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:

<party type="PHYSICAL" sourceSystem="AL" rawId="2">
    <field name=“name">Олег </field>
    <field name="birthdate">02.01.1980</field>
    <attribute type="PHONE" rawId="AL.2.PH.1">
        <field name="type">MOBILE</field>
        <field name="number">+7 916 1234567</field>
    </attribute>
</party>

Давайте разберем эту запись. У нас есть основной элемент party.

У него есть 3 атрибута:

  • type = «PHYSICAL» — тип возвращаемых данных. Нужен, если система умеет работать с разными типами: ФЛ, ЮЛ, ИП. Тогда благодаря этому атрибуту мы понимаем, с чем именно имеем дело и какие поля у нас будут внутри. А они будут отличаться! У физика это может быть ФИО, дата рождения ИНН, а у юр лица — название компании, ОГРН и КПП
  • sourceSystem = «AL» — исходная система. Возможно, нас интересуют только физ лица из одной системы, будем делать отсев по этому атрибуту.
  • rawId = «2» — идентификатор в исходной системе. Он нужен, если мы шлем запрос на обновление клиента, а не на поиск. Как понять, кого обновлять? По связке sourceSystem + rawId!

Внутри party есть элементы field.

У элементов field есть атрибут name. Значение атрибута — название поля: имя, дата рождения, тип или номер телефона. Так мы понимаем, что скрывается под конкретным field.

Это удобно с точки зрения поддержки, когда у вас коробочный продукт и 10+ заказчиков. У каждого заказчика будет свой набор полей: у кого-то в системе есть ИНН, у кого-то нету, одному важна дата рождения, другому нет, и т.д.

Но, несмотря на разницу моделей, у всех заказчиков будет одна XSD-схема (которая описывает запрос и ответ):

— есть элемент party;
— у него есть элементы field;
— у каждого элемента field есть атрибут name, в котором хранится название поля.

А вот конкретные названия полей уже можно не описывать в XSD. Их уже «смотрите в ТЗ». Конечно, когда заказчик один или вы делаете ПО для себя или «вообще для всех», удобнее использовать именованные поля — то есть «говорящие» теги. Какие плюшки у этого подхода:

— При чтении XSD сразу видны реальные поля. ТЗ может устареть, а код будет актуален.
— Запрос легко дернуть вручную в SOAP Ui — он сразу создаст все нужные поля, нужно только значениями заполнить. Это удобно тестировщику + заказчик иногда так тестирует, ему тоже хорошо.

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

Помимо элементов field в party есть элемент attribute. Не путайте xml-нотацию и бизнес-прочтение:

  • с точки зрения бизнеса это атрибут физ лица, отсюда и название элемента — attribute.
  • с точки зрения xml — это элемент (не атрибут!), просто его назвали attribute. XML все равно (почти), как вы будете называть элементы, так что это допустимо.

У элемента attribute есть атрибуты:

  • type = «PHONE» — тип атрибута. Они ведь разные могут быть: телефон, адрес, емейл…
  • rawId = «AL.2.PH.1» — идентификатор в исходной системе. Он нужен для обновления. Ведь у одного клиента может быть несколько телефонов, как без ID понять, какой именно обновляется?

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

Но прочитать даже огромную XML не составит труда, если вы знаете, что где. И если она отформатирована — вложенные элементы сдвинуты вправо, остальные на одном уровне. Без форматирования будет тяжеловато…

А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.

XML пролог

Иногда вверху XML документа можно увидеть что-то похожее:

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

Эта строка называется XML прологом. Она показывает версию XML, который используется в документе, а также кодировку. Пролог необязателен, если его нет — это ок. Но если он есть, то это должна быть первая строка XML документа.

UTF-8 — кодировка XML документов по умолчанию.

XSD-схема

XSD (XML Schema Definition) — это описание вашего XML. Как он должен выглядеть, что в нем должно быть? Это ТЗ, написанное на языке машины — ведь схему мы пишем… Тоже в формате XML! Получается XML, который описывает другой XML.

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

Если мы создаем SOAP-метод, то указываем в схеме:

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

Теперь, когда к нам приходит какой-то запрос, он сперва проверяется на корректность по схеме. Если запрос правильный, запускаем метод, отрабатываем бизнес-логику. А она может быть сложной и ресурсоемкой! Например, сделать выборку из многомиллионной базы. Или провести с десяток проверок по разным таблицам базы данных…

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

Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!

А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?

  1. Разработчик системы, использующей ваше API — ему надо прописать в коде, что именно отправлять из его системы в вашу.
  2. Тестировщик, которому надо это самое API проверить — ему надо понимать, как формируется запрос.

Да-да, в идеале у нас есть подробное ТЗ, где всё хорошо описано. Но увы и ах, такое есть не всегда. Иногда ТЗ просто нет, а иногда оно устарело. А вот схема не устареет, потому что обновляется при обновлении кода. И она как раз помогает понять, как запрос должен выглядеть.

Итого, как используется схема при разработке SOAP API:

  • Наш разработчик пишет XSD-схему для API запроса: нужно передать элемент такой-то, у которого будут такие-то дочерние, с такими-то типами данных. Эти обязательные, те нет.
  • Разработчик системы-заказчика, которая интегрируется с нашей, читает эту схему и строит свои запросы по ней.
  • Система-заказчик отправляет запросы нам.
  • Наша система проверяет запросы по XSD — если что-то не так, сразу отлуп.
  • Если по XSD запрос проверку прошел — включаем бизнес-логику!

А теперь давайте посмотрим, как схема может выглядеть! Возьмем для примера метод doRegister в Users. Чтобы отправить запрос, мы должны передать email, name и password. Есть куча способов написать запрос правильно и неправильно:

Попробуем написать для него схему. В запросе должны быть 3 элемента (email, name, password) с типом «string» (строка). Пишем:

<xs:element name="doRegister ">
   <xs:complexType>
   <xs:sequence>
     <xs:element name="email" type="xs:string"/>
     <xs:element name="name" type="xs:string"/>
     <xs:element name="password" type="xs:string"/>
   </xs:sequence>
   </xs:complexType>
</xs:element>

А в WSDl сервиса она записана еще проще:

<message name="doRegisterRequest">
   <part name="email" type="xsd:string"/>
   <part name="name" type="xsd:string"/>
   <part name="password" type="xsd:string"/>
</message>

Конечно, в схеме могут быть не только строковые элементы. Это могут быть числа, даты, boolean-значения и даже какие-то свои типы:

<xsd:complexType name="Test">
   <xsd:sequence>
     <xsd:element name="value"   type="xsd:string"/>
     <xsd:element name="include" type="xsd:boolean" minOccurs="0" default="true"/>
     <xsd:element name="count" type="xsd:int" minOccurs="0" length="20"/>
     <xsd:element name="user" type="USER" minOccurs="0"/>
   </xsd:sequence>
</xsd:complexType>

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

См также:
XSD — умный XML — полезная статья с хабра
Язык определения схем XSD — тут удобные таблички со значениями, которые можно использовать
Язык описания схем XSD (XML-Schema)
Пример XML схемы в учебнике
Официальный сайт w3.org

Практика: составляем свой запрос

Ок, теперь мы знаем, как «прочитать» запрос для API-метода в формате XML. Но как его составить по ТЗ? Давайте попробуем. Смотрим в документацию. И вот почему я даю пример из Дадаты — там классная документация!

Что, если я хочу, чтобы мне вернулись только женские ФИО, начинающиеся на «Ан»? Берем наш исходный пример:

<req>
  <query>Виктор Иван</query>
  <count>7</count>
</req>

В первую очередь меняем сам запрос. Теперь это уже не «Виктор Иван», а «Ан»:

<req>
  <query>Ан</query>
  <count>7</count>
</req>

Далее смотрим в ТЗ. Как вернуть только женские подсказки? Есть специальный параметр — gender. Название параметра — это название тегов. А внутри уже ставим пол. «Женский» по английски будет FEMALE, в документации также. Итого получили:

<req>
  <query>Ан</query>
  <count>7</count>
  <gender>FEMALE</gender>
</req>

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

<req>
  <query>Ан</query>
  <gender>FEMALE</gender>
</req>

Вот и все! Взяли за основу пример, поменяли одно значение, один параметр добавили, один удалили. Не так уж и сложно. Особенно, когда есть подробное ТЗ и пример )))

Попробуй сам!
Напишите запрос для метода MagicSearch в Users. Мы хотим найти всех Ивановых по полному совпадению, на которых висят актуальные задачи.

Well Formed XML

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. XML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:

  1. Есть корневой элемент.
  2. У каждого элемента есть закрывающийся тег.
  3. Теги регистрозависимы!
  4. Соблюдается правильная вложенность элементов.
  5. Атрибуты оформлены в кавычках.

Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

См также:
Сообщения об ошибках — тоже документация, тестируйте их! — зачем тестировать сообщения об ошибках

1. Есть корневой элемент

Нельзя просто положить рядышком 2 XML и полагать, что «система сама разберется, что это два запроса, а не один». Не разберется. Потому что не должна.

И если у вас будет лежать несколько тегов подряд без общего родителя — это плохой xml, не well formed. Всегда должен быть корневой элемент:

Что мы делаем для тестирования этого условия? Правильно, удаляем из нашего запроса корневые теги!

2. У каждого элемента есть закрывающийся тег

Тут все просто — если тег где-то открылся, он должен где-то закрыться. Хотите сломать? Удалите закрывающийся тег любого элемента.

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

<name/>

Это тоже самое, что передать в нем пустое значение

<name></name>

Аналогично сервер может вернуть нам пустое значение тега. Можно попробовать послать пустые поля в Users в методе FullUpdateUser. И в запросе это допустимо (я отправила пустым поле name1), и в ответе SOAP Ui нам именно так и отрисовывает пустые поля.

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

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

3. Теги регистрозависимы

Как написали открывающий — также пишем и закрывающий. ТОЧНО ТАК ЖЕ! А не так, как захотелось.

А вот для тестирования меняем регистр одной из частей. Такой XML будет невалидным

4. Правильная вложенность элементов

Элементы могут идти друг за другом

Один элемент может быть вложен в другой

Но накладываться друг на друга элементы НЕ могут!

5. Атрибуты оформлены в кавычках

Даже если вы считаете атрибут числом, он будет в кавычках:

<query attr1=“123”>Виктор Иван</query>
<query attr1=“атрибутик” attr2=“123” >Виктор Иван</query>

Для тестирования пробуем передать его без кавычек:

<query attr1=123>Виктор Иван</query>

Итого

XML (eXtensible Markup Language) используется для хранения и передачи данных.

Передача данных — это запросы и ответы в API-методах. Если вы отправляете SOAP-запрос, вы априори работаете именно с этим форматом. Потому что SOAP передает данные только в XML. Если вы используете REST, то там возможны варианты — или XML, или JSON.

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

Вот пример использования XML в коде open-source проекта folks. Я не знаю, что именно делает JacksonJsonProvider, но могу «прочитать» этот код — есть функционал, который мы будем использовать (featuresToEnable), и есть тот, что нам не нужен(featuresToDisable).

Формат XML подчиняется стандартам. Синтаксически некорректный запрос даже на сервер не уйдет, его еще клиент порежет. Сначала проверка на well formed, потом уже бизнес-логика.

Правила well formed XML:

  1. Есть корневой элемент.
  2. У каждого элемента есть закрывающийся тег.
  3. Теги регистрозависимы!
  4. Соблюдается правильная вложенность элементов.
  5. Атрибуты оформлены в кавычках.

Если вы тестировщик, то при тестировании запросов в формате XML обязательно попробуйте нарушить каждое правило! Да, система должна уметь обрабатывать такие ошибки и возвращать адекватное сообщение об ошибке. Но далеко не всегда она это делает.

А если система публичная и возвращает пустой ответ на некорректный запрос — это плохо. Потому что разработчик другой системы налажает в запросе, а по пустому ответу даже не поймет, где именно. И будет приставать к поддержке: «Что же у меня не так?», кидая информацию по кусочкам и в виде скринов исходного кода. Оно вам надо? Нет? Тогда убедитесь, что система выдает понятное сообщение об ошибке!

См также:

Что такое XML
Учебник по XML
Изучаем XML. Эрик Рэй (книга по XML)
Заметки о XML и XLST

Что такое JSON — второй популярный формат

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Если вы тестируете API, то должны знать про два основных формата передачи данных:

  • XML — используется в SOAP (всегда) и REST-запросах (реже);
  • JSON — используется в REST-запросах.

Сегодня я расскажу вам про XML. В списке доп литературы будет ссылка на книгу по XML, у меня нет цели ее дублировать, но я расскажу про этот формат тем, кто XML еще в глаза не видел. А дальше уже гуглим сами ))

Ссылка на Хабр (там содержание кликабельное)

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.

Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!

См также:

Что такое API — общее знакомство с API

Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

Так что давайте разберемся, как он выглядит, как его читать, и как ломать! Да-да, а куда же без этого? Надо ведь выяснить, как отреагирует система на кривой формат присланных данных.

Содержание

  • Как устроен XML
    • Теги
    • Корневой элемент
    • Значение элемента
    • Атрибуты элемента
    • XML пролог
    • XSD-схема
    • Практика: составляем свой запрос
  • Well Formed XML
    • 1. Есть корневой элемент
    • 2. У каждого элемента есть закрывающийся тег
    • 3. Теги регистрозависимы
    • 4. Правильная вложенность элементов
    • 5. Атрибуты оформлены в кавычках
  • Итого

Возьмем пример из документации подсказок Дадаты по ФИО:

<req>

<query>Виктор Иван</query>

<count>7</count>

</req>

И разберемся, что означает эта запись.

Теги

В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки: <tag>. Текст внутри угловых скобок — название тега.

Тега всегда два:

  1. Открывающий — текст внутри угловых скобок (<tag>)
  2. Закрывающий — тот же текст (это важно!), но добавляется символ «/» (</tag>)

Ой, ну ладно, подловили! Не всегда. Бывают еще пустые элементы, у них один тег и открывающий, и закрывающий одновременно. Но об этом чуть позже!

С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается». Это как дорожные знаки:

— На въезде в город написано его название: Москва

— На выезде написано то же самое название, но перечеркнутое: Москва*

* Пример с дорожными знаками я когда-то давно прочитала в статье Яндекса, только ссылку уже не помню. А пример отличный!

Корневой элемент

В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. В случае REST API документ — это запрос, который отправляет система. Или ответ, который она получает.

Чтобы обозначить этот запрос, нам нужен корневой элемент. В подсказках корневой элемент — «req».

Он мог бы называться по другому:

<main>

<sugg>

Да как угодно. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа — сам запрос. Те параметры, которые мы передаем внешней системе. Разумеется, они тоже будут в тегах, но уже в обычных, а не корневых.

Значение элемента

Значение элемента хранится между открывающим и закрывающим тегами. Это может быть число, строка, или даже вложенные теги!

Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.

Внутри — значение запроса.

Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):

Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.

Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».

Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.

Откройте консоль разработчика через f12, вкладку Network, и посмотрите, какой запрос отправляется на сервер. Там будет значение count = 7.

См также:

Что тестировщику надо знать про панель разработчика — подробнее о том, как использовать консоль.

Обратите внимание:

  • Виктор Иван — строка
  • 7 — число

Но оба значения идут без кавычек. В XML нам нет нужды брать строковое значение в кавычки (а вот в JSON это сделать придется).

Атрибуты элемента

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

название_атрибута = «значение атрибута»

Например:

<query attr1=“value 1”>Виктор Иван</query>

<query attr1=“value 1” attr2=“value 2”>Виктор Иван</query>

Зачем это нужно? Из атрибутов принимающая API-запрос система понимает, что такое ей вообще пришло.

Например, мы делаем поиск по системе, ищем клиентов с именем Олег. Отправляем простой запрос:

<query>Олег</query>

А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:

<party type=»PHYSICAL» sourceSystem=»AL» rawId=»2″>

    <field name=“name»>Олег </field>

    <field name=»birthdate»>02.01.1980</field>

    <attribute type=»PHONE» rawId=»AL.2.PH.1″>

        <field name=»type»>MOBILE</field>

        <field name=»number»>+7 916 1234567</field>

    </attribute>

</party>

Давайте разберем эту запись. У нас есть основной элемент party.

У него есть 3 атрибута:

  • type = «PHYSICAL» — тип возвращаемых данных. Нужен, если система умеет работать с разными типами: ФЛ, ЮЛ, ИП. Тогда благодаря этому атрибуту мы понимаем, с чем именно имеем дело и какие поля у нас будут внутри. А они будут отличаться! У физика это может быть ФИО, дата рождения ИНН, а у юр лица — название компании, ОГРН и КПП
  • sourceSystem = «AL» — исходная система. Возможно, нас интересуют только физ лица из одной системы, будем делать отсев по этому атрибуту.
  • rawId = «2» — идентификатор в исходной системе. Он нужен, если мы шлем запрос на обновление клиента, а не на поиск. Как понять, кого обновлять? По связке sourceSystem + rawId!

Внутри party есть элементы field.

У элементов field есть атрибут name. Значение атрибута — название поля: имя, дата рождения, тип или номер телефона. Так мы понимаем, что скрывается под конкретным field.

Это удобно с точки зрения поддержки, когда у вас коробочный продукт и 10+ заказчиков. У каждого заказчика будет свой набор полей: у кого-то в системе есть ИНН, у кого-то нету, одному важна дата рождения, другому нет, и т.д.

Но, несмотря на разницу моделей, у всех заказчиков будет одна XSD-схема (которая описывает запрос и ответ):

— есть элемент party;

— у него есть элементы field;

— у каждого элемента field есть атрибут name, в котором хранится название поля.

А вот конкретные названия полей уже можно не описывать в XSD. Их уже «смотрите в ТЗ». Конечно, когда заказчик один или вы делаете ПО для себя или «вообще для всех», удобнее использовать именованные поля — то есть «говорящие» теги. Какие плюшки у этого подхода:

— При чтении XSD сразу видны реальные поля. ТЗ может устареть, а код будет актуален.

— Запрос легко дернуть вручную в SOAP Ui — он сразу создаст все нужные поля, нужно только значениями заполнить. Это удобно тестировщику + заказчик иногда так тестирует, ему тоже хорошо.

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

Помимо элементов field в party есть элемент attribute. Не путайте xml-нотацию и бизнес-прочтение:

  • с точки зрения бизнеса это атрибут физ лица, отсюда и название элемента — attribute.
  • с точки зрения xml — это элемент (не атрибут!), просто его назвали attribute. XML все равно (почти), как вы будете называть элементы, так что это допустимо.

У элемента attribute есть атрибуты:

  • type = «PHONE» — тип атрибута. Они ведь разные могут быть: телефон, адрес, емейл…
  • rawId = «AL.2.PH.1» — идентификатор в исходной системе. Он нужен для обновления. Ведь у одного клиента может быть несколько телефонов, как без ID понять, какой именно обновляется?

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

Но прочитать даже огромную XML не составит труда, если вы знаете, что где. И если она отформатирована — вложенные элементы сдвинуты вправо, остальные на одном уровне. Без форматирования будет тяжеловато…

А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.

XML пролог

Иногда вверху XML документа можно увидеть что-то похожее:

<?xml version=»1.0″ encoding=»UTF-8″?>

Эта строка называется XML прологом. Она показывает версию XML, который используется в документе, а также кодировку. Пролог необязателен, если его нет — это ок. Но если он есть, то это должна быть первая строка XML документа.

UTF-8 — кодировка XML документов по умолчанию.

XSD-схема

XSD (XML Schema Definition) — это описание вашего XML. Как он должен выглядеть, что в нем должно быть? Это ТЗ, написанное на языке машины — ведь схему мы пишем… Тоже в формате XML! Получается XML, который описывает другой XML.

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

Если мы создаем SOAP-метод, то указываем в схеме:

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

Теперь, когда к нам приходит какой-то запрос, он сперва проверяется на корректность по схеме. Если запрос правильный, запускаем метод, отрабатываем бизнес-логику. А она может быть сложной и ресурсоемкой! Например, сделать выборку из многомиллионной базы. Или провести с десяток проверок по разным таблицам базы данных…

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

Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!

А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?

  1. Разработчик системы, использующей ваше API — ему надо прописать в коде, что именно отправлять из его системы в вашу.
  2. Тестировщик, которому надо это самое API проверить — ему надо понимать, как формируется запрос.

Да-да, в идеале у нас есть подробное ТЗ, где всё хорошо описано. Но увы и ах, такое есть не всегда. Иногда ТЗ просто нет, а иногда оно устарело. А вот схема не устареет, потому что обновляется при обновлении кода. И она как раз помогает понять, как запрос должен выглядеть.

Итого, как используется схема при разработке SOAP API:

  • Наш разработчик пишет XSD-схему для API запроса: нужно передать элемент такой-то, у которого будут такие-то дочерние, с такими-то типами данных. Эти обязательные, те нет.
  • Разработчик системы-заказчика, которая интегрируется с нашей, читает эту схему и строит свои запросы по ней.
  • Система-заказчик отправляет запросы нам.
  • Наша система проверяет запросы по XSD — если что-то не так, сразу отлуп.
  • Если по XSD запрос проверку прошел — включаем бизнес-логику!

А теперь давайте посмотрим, как схема может выглядеть! Возьмем для примера метод doRegister в Users. Чтобы отправить запрос, мы должны передать email, name и password. Есть куча способов написать запрос правильно и неправильно:

Правильный запрос

Неправильный запрос

<wrap:doRegister>

<email>olga@gmail.com</email>

<name>Ольга</name>

<password>1</password>

</wrap:doRegister>

<wrap:doRegister>

<email>name@gmail.com</email>

<password>1</password>

</wrap:doRegister>

Нет обязательного поля name

<wrap:doRegister>

<email>maxim@gmail.com</email>

<name>*(&$%*($</name>

<password>Парольчик</password>

</wrap:doRegister>

<wrap:doRegister>

<mail>test@gmail.com</mail>

<name>Test</name>

<password>1</password>

</wrap:doRegister>

Опечатка в названии тега (mail вместо email)

Попробуем написать для него схему. В запросе должны быть 3 элемента (email, name, password) с типом «string» (строка). Пишем:

<xs:element name=»doRegister «>

   <xs:complexType>

   <xs:sequence>

     <xs:element name=»email» type=»xs:string»/>

     <xs:element name=»name» type=»xs:string»/>

     <xs:element name=»password» type=»xs:string»/>

   </xs:sequence>

   </xs:complexType>

</xs:element>

А в WSDl сервиса она записана еще проще:

<message name=»doRegisterRequest»>

   <part name=»email» type=»xsd:string»/>

   <part name=»name» type=»xsd:string»/>

   <part name=»password» type=»xsd:string»/>

</message>

Конечно, в схеме могут быть не только строковые элементы. Это могут быть числа, даты, boolean-значения и даже какие-то свои типы:

<xsd:complexType name=»Test»>

   <xsd:sequence>

     <xsd:element name=»value»   type=»xsd:string»/>

     <xsd:element name=»include» type=»xsd:boolean» minOccurs=»0″ default=»true»/>

     <xsd:element name=»count» type=»xsd:int» minOccurs=»0″ length=»20″/>

     <xsd:element name=»user» type=»USER» minOccurs=»0″/>

   </xsd:sequence>

</xsd:complexType>

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

См также:

XSD — умный XML — полезная статья с хабра

Язык определения схем XSD — тут удобные таблички со значениями, которые можно использовать

Язык описания схем XSD (XML-Schema)

Пример XML схемы в учебнике

Официальный сайт w3.org

Практика: составляем свой запрос

Ок, теперь мы знаем, как «прочитать» запрос для API-метода в формате XML. Но как его составить по ТЗ? Давайте попробуем. Смотрим в документацию. И вот почему я даю пример из Дадаты — там классная документация!

Что, если я хочу, чтобы мне вернуть только женские ФИО, начинающиеся на «Ан»? Берем наш исходный пример:

<req>

  <query>Виктор Иван</query>

  <count>7</count>

</req>

В первую очередь меняем сам запрос. Теперь это уже не «Виктор Иван», а «Ан»:

<req>

  <query>Ан</query>

  <count>7</count>

</req>

Далее смотрим в ТЗ. Как вернуть только женские подсказки? Есть специальный параметр — gender. Название параметра — это название тегов. А внутри уже ставим пол. «Женский» по английски будет FEMALE, в документации также. Итого получили:

<req>

  <query>Ан</query>

  <count>7</count>

  <gender>FEMALE</gender>

</req>

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

<req>

  <query>Ан</query>

  <gender>FEMALE</gender>

</req>

Вот и все! Взяли за основу пример, поменяли одно значение, один параметр добавили, один удалили. Не так уж и сложно. Особенно, когда есть подробное ТЗ и пример )))

Попробуй сам!

Напишите запрос для метода MagicSearch в Users. Мы хотим найти всех Ивановых по полному совпадению, на которых висят актуальные задачи.

Well Formed XML

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. XML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:

  1. Есть корневой элемент.
  2. У каждого элемента есть закрывающийся тег.
  3. Теги регистрозависимы!
  4. Соблюдается правильная вложенность элементов.
  5. Атрибуты оформлены в кавычках.

Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

См также:

Сообщения об ошибках — тоже документация, тестируйте их! — зачем тестировать сообщения об ошибках

1. Есть корневой элемент

Нельзя просто положить рядышком 2 XML и полагать, что «система сама разберется, что это два запроса, а не один». Не разберется. Потому что не должна.

И если у вас будет лежать несколько тегов подряд без общего родителя — это плохой xml, не well formed. Всегда должен быть корневой элемент:

НЕТ

ДА

<test>

  <user>Тест</user>

  <pass>123</pass>

</test>

<dev>

  <user>Антон</user>

  <pass>123</pass>

</dev>

Есть элементы test и dev, но они
расположены рядом, а корневого, внутри которого все лежит — нету. Это
скорее похоже на 2
XML документа

<credential>

  <test>

    <user>Тест</user>

    <pass>123</pass>

  </test>

  <dev>

    <user>Антон</user>

    <pass>123</pass>

 
</
dev>

</credential>

А вот тут уже есть элемент credential,
который является корневым

Что мы делаем для тестирования этого условия? Правильно, удаляем из нашего запроса корневые теги!

2. У каждого элемента есть закрывающийся тег

Тут все просто — если тег где-то открылся, он должен где-то закрыться. Хотите сломать? Удалите закрывающийся тег любого элемента.

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

<name/>

Это тоже самое, что передать в нем пустое значение

<name></name>

Аналогично сервер может вернуть нам пустое значение тега. Можно попробовать послать пустые поля в Users в методе FullUpdateUser. И в запросе это допустимо (я отправила пустым поле name1), и в ответе SOAP Ui нам именно так и отрисовывает пустые поля.

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

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

НЕТ

ДА

<user>Тест

<user>Тест</user>

Тест</user>

<user/>

3. Теги регистрозависимы

Как написали открывающий — также пишем и закрывающий. ТОЧНО ТАК ЖЕ! А не так, как захотелось.

А вот для тестирования меняем регистр одной из частей. Такой XML будет невалидным

НЕТ

ДА

<Name>Тест</name>

<NAME>Иван</name>

<NAME>Тест</name>

<name>Тест</name>

4. Правильная вложенность элементов

Элементы могут идти друг за другом

Один элемент может быть вложен в другой

Но накладываться друг на друга элементы НЕ могут!

НЕТ

ДА

<fio>Иванов <name>Иван</fio>

Иванович </name>

<fio>Иванов ИванИванович</fio>

<name> Иван </name>

<fio>Иванов <b> <name>Иван</name> Иванович</fio></b>

<fio>Иванов <name>Иван</name> Иванович</fio>

5. Атрибуты оформлены в кавычках

Даже если вы считаете атрибут числом, он будет в кавычках:

<query attr1=“123”>Виктор Иван</query>

<query attr1=“атрибутик” attr2=“123” >Виктор Иван</query>

Для тестирования пробуем передать его без кавычек:

<query attr1=123>Виктор Иван</query>

Итого

XML (eXtensible Markup Language) используется для хранения и передачи данных.

Передача данных — это запросы и ответы в API-методах. Если вы отправляете SOAP-запрос, вы априори работаете именно с этим форматом. Потому что SOAP передает данные только в XML. Если вы используете REST, то там возможны варианты — или XML, или JSON.

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

Вот пример использования XML в коде open-source проекта folks. Я не знаю, что именно делает JacksonJsonProvider, но могу «прочитать» этот код — есть функционал, который мы будем использовать (featuresToEnable), и есть тот, что нам не нужен(featuresToDisable).

Формат XML подчиняется стандартам. Синтаксически некорректный запрос даже на сервер не уйдет, его еще клиент порежет. Сначала проверка на well formed, потом уже бизнес-логика.

Правила well formed XML:

  1. Есть корневой элемент.
  2. У каждого элемента есть закрывающийся тег.
  3. Теги регистрозависимы!
  4. Соблюдается правильная вложенность элементов.
  5. Атрибуты оформлены в кавычках.

Если вы тестировщик, то при тестировании запросов в формате XML обязательно попробуйте нарушить каждое правило! Да, система должна уметь обрабатывать такие ошибки и возвращать адекватное сообщение об ошибке. Но далеко не всегда она это делает.

А если система публичная и возвращает пустой ответ на некорректный запрос — это плохо. Потому что разработчик другой системы налажает в запросе, а по пустому ответу даже не поймет, где именно. И будет приставать к поддержке: «Что же у меня не так?», кидая информацию по кусочкам и в виде скринов исходного кода. Оно вам надо? Нет? Тогда убедитесь, что система выдает понятное сообщение об ошибке!

См также:

Что такое XML

Учебник по XML

Изучаем XML. Эрик Рэй (книга по XML)

Заметки о XML и XLST

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моих курсов — по автоматизации в Postman и по тестированию REST API

Проект seo-tools поддерживает xml запросы для предоставления данных.

  

  Вы покупатель seo-tools — Прочтите!

Полное копирование текстов справки с демонстрационного сайта проекта

http://seo-tools.forwebm.net

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

http://seo-tools.forwebm.net

тексты справок в качестве основы, но Вы не имеете права копировать их полностью на свои ресурсы.

Точка запроса:

Адрес для отправки запросов:

http://seo-tools.forwebm.net/xml/

Метод запроса: POST
Кодировка запроса: UTF-8

Составление xml запроса  [ пример запроса на php ]

Вид стандартного xml запроса (без указания параметров api для получения конкретных данных)

<?xml version="1.0" encoding="UTF-8"?>
<request>
<charset>кодировка ответа</charset>
<code>api код</code>
<apitype>тип возвращаемых данных</apitype>

</request>


<charset></charset> — Указывается кодировка, в которой необходимо возвращать данные, например: windows-1251 или utf-8. Если оставить пустым или вовсе не указать данный тэг — по умолчанию данные будут возвращаться в кодировке UTF-8
Пример:

<?xml version="1.0" encoding="UTF-8"?>
<request>
<charset>windows-1251</charset>

</request>


<code></code> — Указывается персональный api код, необходимый для предоставления доступа к api seo-tools. Данный код можно взять со страницы управления api Вашего кабинета.
Пример:

<?xml version="1.0" encoding="UTF-8"?>
<request>
<code>9b3d80e69fe1a4e0a5df52a3c32b04f2</code>

</request>


<apitype></apitype> — Указывает на тип получаемых данных. Ограничено в диапазоне и функционально исключительно в рамках допустимых типов. Типы api приведены в соответствующих записях текущего раздела справки. Например, для получения апдейтов поисковиков используется тип `updates` и т.д. В соответствующих записях справки тип указывается.
Пример:

<?xml version="1.0" encoding="UTF-8"?>
<request>
<apitype>updates</apitype>

</request>


Существует еще один тэг, который учитывается при составлении запроса:
<error></error> — Данный тэг не обязательный. Используется для возможности получения описания ошибки в случае её возникновения (текст ошибки возвращается на английском языке). По умолчанию в случае ошибки возвращается только код ошибки (см. ниже по тексту), для получения +описания ошибки необходимо добавить в тело запроса тэг <error> со значением 1.
Пример:

<?xml version="1.0" encoding="UTF-8"?>
<request>
<error>1</error>

</request>


Описаны стандартные поля для составления запроса. В зависимости от типа запроса могут добавляться другие поля к уже описанным выше (все дополнительные поля описываются в соответствующей типу api справке).

Пример отправки xml запроса средствами php используя библиотеку cURL
Пример:


<?php
function PostXML($link$xml) { 

   
$chx curl_init();

   
curl_setopt($chxCURLOPT_URL$link);

   
curl_setopt($chxCURLOPT_TIMEOUT90);

   
curl_setopt($chxCURLOPT_RETURNTRANSFER1);

   
curl_setopt($chxCURLOPT_USERAGENT$_SERVER["HTTP_USER_AGENT"]);

   
curl_setopt($chxCURLOPT_POST1);

   
curl_setopt($chxCURLOPT_POSTFIELDS$xml);

   
$result curl_exec($chx);

   
curl_close($chx);

   return 
$result;        

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

 <request>     

    <charset>windows-1251</charset>

    <code>9b3d80e69fe1a4e0a5df52a3c32b04f2</code>

    <apitype>updates</apitype>

    <error>1</error>         

 </request>'
;
$respons PostXML('http://seo-tools.forwebm.net/xml/'$xml);
/* переменная $respons будет содержать xml ответ описанный выше 

    по тексту в кодировке windows-1251 (указана при составлении запроса) */
?>

Структура xml ответа

Вид стандартного xml ответа (пустой):
Пример:

<?xml version="1.0" encoding="кодировка"?>
<seotools version="1.3.3">
<request>
<charset>кодировка</charset>
и остальные тэги, отправленные в запросе
</request>
<response>
<datetime></datetime>
<host></host>
<username></username>
<results>
результат взависимости от типа api
</results>
</response>
</seotools>


<datetime></datetime> — Содержит текущую дату и время запроса в формате: Y-m-d H:i:s
<host></host> — Содержит хост сайта проекта (т.е seo-tools.forwebm.net)
<username></username> — Содержит логин пользователя, чей api код был использован для подачи запроса. Может отсутствовать в случае возникновения ошибки составления запроса.
Пример:

<?xml version="1.0" encoding="WINDOWS-1251"?>
<seotools version="1.3.3">
<request>

</request>
<response>
<datetime>2011-09-06 21:20:27</datetime>
<host>seo-tools.forwebm.net</host>
<username>admin</username>

<results>

</results>
</response>
</seotools>


<results></results> — Содержит вложенную xml структуру ответа в зависимости от типа api (в справке соответствующего типа api структура подробно описывается, см. необходимый тип api)

В случае, если возникает какая-либо ошибка — тэг results будет отсутствовать, но появится тэг errorcode, который будет содержать код ошибки.

Описание кодов ошибок:


1 — Пустой xml запрос
2 — Отправлен некорректный запрос
3 — Не указан hash код пользователя
4 — Не определен тип возвращаемых xml данных
5 — Неизвестный тип возвращаемых xml данных
6 — Api недоступен или отключен администратором
7 — Неверный hash код пользователя
8 — Аккаунт не поддерживает xml api
9 — Вы исчерпали дневной лимит запросов для используемого типа api
10 — На Вашем счете недостаточно средств для выполнения запросов
11 — Произошла ошибка при оплате выполнения запросов


В данном списке приведен `стандартный` список ошибок при составлении и идентификации запроса. Описание кодов ошибок определенных типов описывается в соответствующем типу api разделе справки.

Если в запрос был включен тэг <error>1</error>, в таком случае к ответу также будет добавлен тэг error, содержащий описание ошибки (на английском языке).
Пример:

<?xml version="1.0" encoding="WINDOWS-1251"?>
<seotools version="1.3.3">
<request>
<charset>WINDOWS-1251</charset>
<code>9b3d80e69fe1a4e0a5df52a3c32b04f2</code>
<apitype>updates</apitype>
<error>1</error>
</request>
<response>
<datetime>2011-09-06 21:20:27</datetime>
<host>seo-tools.forwebm.net</host>
<username>admin</username>
<errorcode>8</errorcode>
<error>Account does not support xml api</error>
</response>
</seotools>


2003 г

XQuery: язык запросов XML

Дон Чемберлин
Журнал Открытые системы #01/2003

Консорциум World Wide Web Consortium (W3C) образовал рабочую группу для разработки языка запросов к источникам данных, представленных на языке XML. Этот язык запросов, получивший название XQuery, развивается до сих пор и описан в серии предварительных документов. XQuery — функциональный язык, состоящий из нескольких видов выражений, которые могут использоваться в разных сочетаниях. Язык базируется на системе типов XML Schema и совместим с другими стандартами, связанными с XML. В статье объясняются причины создания языка запросов XML, предлагается вводное описание XQuery и приводится несколько примеров его использования.

Язык XML [1] все чаще применяется в качестве формата для обмена информацией между разными приложениями в Internet. Популярность XML во многом объясняется его гибкостью при представлении разных видов информации. Применение тегов делает XML-данные самоописываемыми, а расширяемая природа XML позволяет определять новые виды специализированных документов. По мере роста значимости XML создается целая серия стандартов, многие из которых были подготовлены консорциумом W3C [2]. Так, XML Schema [3] обеспечивает нотацию для определения новых типов элементов и документов; XML Path Language (XPath) [4] — нотацию для выбора элементов в документе XML; Extensible Stylesheet Language Transformations (XSLT) [5] — нотацию для преобразования документов XML из одного представления в другое.

XML позволяет приложениям обмениваться данными в стандартном формате, не зависящем от способа их хранения. Скажем, одно приложение может использовать естественный для XML формат хранения, а другое — хранить данные в реляционной базе данных. Поскольку XML все больше утверждается в роли стандарта для обмена данными, естественно, что запросы, поступающие от приложений, должны быть выражены как запросы к данным в формате XML. Это вызывает потребность в языке запросов, явно ориентированном на источники XML-данных. В октябре 1999 года W3C образовал рабочую группу XML Query Working Group [6] с целью разработки такого языка запросов, получившего название XQuery.

В XML-документах имеется внутренний порядок, а реляционные данные неупорядочены, если не принимать во внимание те случаи, когда порядок можно определить на основе значений данных. Реляционные данные обычно являются <плотными> (т.е. почти в каждом столбце имеется значение), а отсутствующая информация в реляционных системах часто представляется специальным значением null. XML-данные часто бывают <разреженными>, а отсутствие информации может представляться отсутствием элемента. По этим и другим причинам имеющиеся языки реляционных запросов не подходят напрямую для запросов XML-данных.

Разработка XQuery все еще продолжается. XML Query Working Group опубликовала предварительные рабочие версии нескольких документов, описывающие существующее состояние разработки. Возможно, наиболее важным из них является документ XQuery 1.0: An XMLQuery Language [7], содержащий синтаксис и неформальное описание языка. Кроме того, рабочая группа опубликовала список требований [8], описание модели данных, положенной в основу языка [9], формальное описание семантики [10], список функций и операторов [11], а также примеры, иллюстрирующие применение этого языка [12]. Каждый из этих документов обновляется по мере дальнейшего развития XQuery. Данная статья опирается на самую последнюю к моменту публикации версию языка.

На разработку XQuery влияет целый ряд факторов. Возможно, важнее всего совместимость с существующими стандартами W3C, в том числе, XML Schema, XSLT, XPath и сам XML. В частности, язык XPath настолько тесно связан с XQuery, что XQuery определяется как надмножество XPath. Общая структура XQuery базируется на предварительной версии языка, получившей название Quilt [13]. В свою очередь, на создание Quilt оказали влияние функциональный подход языка OQL (Object Query Language) [14], синтаксис на основе ключевых слов языка SQL [15] и предыдущие предварительные версии языка запросов XML, в том числе XQL [16], XML-QL [17] и Lorel [18].

Цель XML Query Working Group — определение двух видов синтаксиса XQuery: один из них выражается на XML, а другой оптимизирован для восприятия человеком. В этой статье описывается только <человеческий> вариант XQuery.

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

В данной статье описывается модель данных, на которой основан XQuery, а затем представляется обзор языка XQuery в виде серии примеров. Синтаксис XQuery и более полное описание самого языка можно найти в [7].

Модель данных

Формально входные и выходные данные XQuery определяются в терминах модели данных, описанной в [9]. <Запросная> модель данных обеспечивает абстрактное представление одного или нескольких документах или фрагментов XML-документов. Модель данных опирается на понятие последовательности. Последовательность (sequence) — это упорядоченный набор нулевого или большего числа объектов. Объект (item) может быть узлом или атомарным значением. Атомарное значение (atomic value) — экземпляр одного из встроенных типов данных, определенных в XML Schema, таких как строки, целые и десятичные числа, даты. Узел (node) соответствует одному из семи видов: элементы, атрибуты, тексты, документы, комментарии, команды обработки и пространства имен. Узел может иметь другие узлы в качестве потомков, что позволяет образовывать одну или несколько иерархий узлов. Некоторые виды узлов, такие как элементы и атрибуты, имеют имена или типизированные значения, либо и то, и другое. Типизированное значение (typed value) — это последовательность из нуля или большего числа атомарных значений. Узлы индивидуальны (т. е. два узла можно различить, даже если они имеют одинаковые имена и значения), но атомарные величины такой индивидуальностью не обладают. Для всех узлов иерархии имеется полный порядок, называемый порядком документа (document order), в соответствии с которым каждый узел предшествует своему потомку. Порядок документа соответствует порядку, в котором следовали бы узлы, если бы иерархия узлов представлялась в формате XML. Порядок документа между узлами в разных иерархиях определяется в реализации, но он должен быть последовательным, т.е. все узлы одной иерархии должны располагаться либо до, либо после всех узлов другой иерархии.

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

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

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

Входные XML-документы могут быть преобразованы в запросную модель данных с помощью процесса, называемого проверкой корректности по схеме (schema validation). Этот процесс выполняет грамматический разбор документа, проверяет его корректность в соответствии с некоторой схемой и представляет документ в виде иерархии узлов и атомарных значений, помеченных типом полученным из схемы [3]. Если входной документ не имеет схемы, проверка его корректности выполняется в соответствии с используемой по умолчанию рекомендательной схемой, которая присваивает родовые типы — узлы маркируются как anyType, а атомарные величины — как anySimpleType.

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

Данные для примеров

Чтобы проиллюстрировать запросную модель данных и обеспечить основу для последующих примеров, рассмотрим небольшую базу данных, содержащую данные интерактивного аукциона и основанную на Use Case R [12]. Эта база данных содержит два XML-документа с именами items.xml и bids.xml.

Документ items.xml содержит корневой элемент с именем items, который, в свою очередь, содержит элемент item для каждого из товаров, предложенных к продаже на аукционе. Каждый элемент item имеет атрибут status и подэлементы с именами itemno, seller, description, reserve-price и end-date. Элемент reserve-price указывает минимальную продажную цену, установленную владельцем товара, а end-date определяет дату окончания торгов.

Документ bids.xml содержит корневой элемент с именем bids, который, в свою очередь, содержит элемент bid для каждой ставки, которая предлагается за товар. Каждый элемент bid имеет подэлементы с именами itemno, bidder, bid-amount и bid-date.


Рис. 1. Представление модели данных из items.xml

На рис. 1 и 2 показаны модельные представления документов items.xml и bids.xml соответственно (включающие только образцы товара и ставки). Круги, помеченные буквами D, E, A и T, обозначают узлы документов, элементов, атрибутов и тестов соответственно.


Рис. 2. Представление модели данных из bids.xml

Выражения

Теперь опишем выражения XQuery.

Основы. Подобно XML и XPath, в XQuery различаются прописные и строчные буквы, а все ключевые слова состоят из строчных букв. Подробные лексические и грамматические правила XQuery описаны в [7]. Символы, заключенные между <{-> и <-}> считаются комментариями и при обработке запроса игнорируются (конечно, кроме тех случаев, когда они входят в строку, заключенную в кавычки, и считаются частью этой строки).

Простейший вид выражения XQuery — литерал (literal), который представляет атомарное значение.

47	литерал типа integer
4.7	литерал типа decimal,
поскольку он содержит десятичную точку
4.7E3	литерал типа double, 
поскольку он содержит экспоненту
"47"	литерал типа string (внутри 
строки, заключенной в двойные кавычки, 
разрешается помещать одинарные кавычки)

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

date(<2002-5-31>)

Любое выражение XQuery может быть заключено в круглые скобки. Скобки полезны для определения явного порядка вычисления выражения.

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

1, 2, 3	последовательность
 из трех значений
(1, 2, 3)	идентична 1, 2, 3
((1, 2), 3)	идентична 1, 2, 3
1 to 3		идентична 1, 2, 3

Переменная (variable) в XQuery — имя, начинающееся со знака доллара. Переменная может быть связана со значением и использоваться в выражении для представления этого значения. Один из способов связывания переменной состоит в использовании выражения LET, которое связывает одну или несколько переменных, а затем вычисляет внутреннее выражение. Значение выражения LET — результат вычисления внутреннего выражения со связанными переменными. Следующий пример иллюстрирует выражение LET, которое возвращает последовательность 1, 2, 3.

let $start := 1, $stop := 3
return $start to $stop

Выражение LET — частный случай выражения FLWR (for, let, where, return), которое обеспечивает дополнительные способы связывания переменных.

Еще одна простая форма выражений XQuery — вызов функции (function call). XQuery предусматривает наличие базовой библиотеки функций, описанной в [11], и описываемый в следующем разделе механизм, позволяющий пользователям определять дополнительные функции. Вызовы функций в XQuery основаны на обычной нотации с заключением в скобки аргументов функции. В следующем примере вызывается функция базовой библиотеки substring, извлекающая из строки первые шесть символов.

substring(, 1, 6)

Выражения пути. Выражения пути в XQuery базируются на синтаксисе XPath [4]. Выражение пути состоит из серии шагов, разделенных символом слэша (). Результат каждого шага — последовательность узлов. Значение выражения пути — последовательность узлов, которая формируется на последнем шаге.

Каждый шаг вычисляется в контексте некоторого узла, называемого контекстным узлом (context node). В общем случае шаг может быть любым выражением, возвращающим последовательность узлов. Один из важных видов шага, называемый осевым шагом (axis step), можно считать перемещением от контекстного узла по иерархии узлов в некотором направлении, называемом осью (axis). При перемещении по указанной оси осевой шаг выбирает узлы, которые удовлетворяют критерию выбора. Критерий выбора может выбирать узлы на основе их имен, положения по отношению к контекстному узлу или предикату, базирующемуся на значении узла. В XPath определяются 13 осей, и часть из них или все будут поддерживаться и в XQuery. Пока планируется реализовать в XQuery поддержку шести осей: child, descendant, parent, attribute, self и descendant-or-self.

Выражения пути могут быть записаны в полном или в сокращенном синтаксисе. Полный синтаксис для осевого шага предусматривает указание оси и критерия выбора, разделенных парой двоеточий. Q1 иллюстрирует четырехшаговое выражение пути, оформленное в полном синтаксисе. На первом шаге вызывается встроенная функция document, которая возвращает узел-документ документа items.xml. Второй шаг — осевой шаг, который находит всех потомков узла-документа (<*> выбирает все узлы на данной оси; в данном случае будет выбран единственный узел-элемент с именем items). Третий шаг снова выполняет поиск вдоль оси child, чтобы найти на следующем уровне все элементы-потомки с именем item, которые, в свою очередь, имеют потомков с именем seller и значением . Результатом третьего шага является последовательность узлов-элементов item. Каждый из этих узлов item служит контекстным узлом для четвертого шага, который опять предусматривает поиск по оси child элементов description, являющихся потомками данного item. Окончательный результат выражения пути — результат четвертого шага: последовательность узлов-элементов description, перечисленных в порядке документа.

(Q1) Перечислить описания всех товаров, предлагаемых к продаже Смитом.

document("items.xml")/child::*
/child::item [child::seller = "Smith"]
/child::description

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

document("items.xml")
/*/item[seller = "Smith"]/description

Разделение двух шагов двойным, а не одинарным слэшем означает, что второй шаг может выполнять поиск в нескольких уровнях иерархии, используя для этого ось descendants, а не одноуровневую ось child. Так, Q2 выполняет поиск элементов description, которые являются потомками (необязательно прямыми) корневого узла данного документа. Результат Q2 — это последовательность узлов-элементов, которые могут, в принципе, быть найдены на различных уровнях иерархии узлов (хотя в нашем примере все узлы description находятся на одном и том же уровне).

(Q2) Перечислить все элементы описания товаров, имеющиеся в документе items.xml.

document()//description

В выражении пути одинарная точка (<.>) указывает на контекстный узел, а две последовательные точки (<..>) — на предка контекстного узла. Эти нотации представляют собой сокращенное указание осей self и axes соответственно. Имена, присутствующие в выражениях пути, как правило, интерпретируются как имена узлов-элементов, однако если имя имеет префикс <@>, оно интерпретируется как имя узла-атрибута. Это сокращение для шага, который выполняет поиск вдоль оси attribute. Эти аббревиатуры иллюстрируются в Q3, где поиск начинается с узла, связанного с переменной $description, вдоль оси parent к родительскому узлу item, а затем — вдоль оси attribute в поисках атрибута с именем status. Результатом Q3 является единственный узел-атрибут.

(Q3) Найти атрибут статуса для товара, который является предком данного описания товара.

$description/../@status

Предикаты. В XQuery предикат (predicate) — это заключенное в квадратные скобки выражение, которое используется для фильтрации последовательности значений. Предикаты часто применяются в шагах выражения пути. Например, в шаге item[seller = ] фраза seller = — это предикат, который применяется для выбора определенных узлов item и отбрасывания остальных. Будем называть объекты последовательности, фильтруемые с помощью предиката, объектами-кандидатами. Предикат вычисляется для каждого объекта-кандидата с использованием этого объекта-кандидата в качестве контекстного объекта для вычисления выражения предиката. Термин <контекстный объект> — это обобщение термина <контекстный узел>, и ему может соответствовать как узел, так и атомарное значение. В предикатном выражении одинарная точка (<.>) обозначает контекстный объект. Каждый объект-кандидат выбирается или отвергается в соответствии со следующими правилами.

Если в результате вычисления предикатного выражения получается булевское значение, то объект-кандидат выбирается в том случае, если значение предикатного выражение равно true. Этот тип предиката иллюстрируется в примере, где выбираются узлы item, имеющие узел-потомок reserve-price, чье значение больше 1000:

item [reserve-price > 1000]

Если результатом вычисления предикатного выражения является число, то объект-кандидат выбирается в том случае, если его порядковый номер в списке объектов-кандидатов равен этому числу. Такой тип предиката представлен в примере, где выбирается пятый узел item по оси child:

item [5]

Если в результате вычисления предикатного выражения получается пустая последовательность, объект-кандидат отвергается. Однако если результат вычисления предикатного выражения представляет собой последовательность, содержащую хотя бы один узел, объект-кандидат выбирается. Такая форма предиката может применяться для проверки существования узла-потомка, удовлетворяющего некоторому условию. Это иллюстрирует пример, где выбираются узлы item, у которых имеется узел-потомок reserve-price, вне зависимости от его значения:

item [reserve-price]

Внутри предикатов часто используется несколько видов операций и функций.

Операции сравнения значений (value comparison operator): eq, ne, lt, le, gt, ge. Эти операции могут сравнивать два скалярных значения, но порождают ошибку, если любой из операндов является последовательностью с длиной, большей единицы. Если один из операндов — узел, то прежде, чем выполнить сравнение, операция сравнения значений извлекает его значение. Например, item[reserve-price gt 1000] выбирает узел item только в том случае, если он имеет в точности один узел-потомок reserve-price со значением, большим 1000.

Общие операции сравнения (general comparison operator): =, !=, >, >=, <, <=. Эти операции могут работать с операндами, которые представляются собой последовательности, при условии неявного наличия семантики <существования> для обоих операндов. Как и операции сравнения значений, общие операции сравнения автоматически извлекают значения узлов. Например, item[reserve-price = 1000] выбирает узел item, если у него имеется хотя бы один узел-потомок со значением, большим 1000.

Операции сравнения узлов (node comparison operator): is и isnot. Эти операторы определяют идентичность двух узлов. Например, $node1 is $node2 принимает значение <истина>, если переменные $node1 и $node2 связаны с одним и тем же узлом (т. е. для обеих переменных узел один и тот же).

Операции сравнения порядка (order comparison operator). Эти операции сравнивают позиции двух узлов. Например, $node1 << $node2 принимает значенией true, если узел, связанный с $node1, в порядке документа встречается раньше, чем узел, связанный с $node2.

Логические операции (logical operator): and и or. Эти операции могут использоваться для объединения логических условий в предикате. Например, следующий предикат выбирает узлы item, имеющие ровно один элемент-потомок seller со значением , а также, по крайней мере, один элемент-потомок reserve-price с любым значением.

item [seller eq  and reserve-price].

Отрицание (negation): not. Это скорее функция, а не операция. Она служит для инвертирования булевых величин.

Во всех приведенных примерах имена элементов и атрибутов были простыми идентификаторами. Однако в соответствии с рекомендацией XML Namespace [19], элементами и атрибутам позволяется иметь имена, состоящие из двух частей, где первая часть — префикс пространства имен, за которым следует двоеточие. Имя, имеющее префикс пространства имен, называется QName. Каждый префикс пространства имен должен быть связан с URI (универсальный идентификатор ресурсов), который уникальным образом определяет пространство имен. Это соглашение позволяет каждому приложению определять имена в своем собственном пространстве, не опасаясь коллизий с именами, определенными другими приложениями, что дает возможность однозначно ссылаться на имена, указываемые в различных приложениях. Если бы префикс auction был связан с URI пространства имен нашего приложения для проведения интерактивного аукциона, то шаг item [reserve-price > 1000] мог бы быть записан с помощью QName следующим образом:

auction:item [auction:reserve-price > 1000]

Процесс связывания префикса с URI пространства имен описан в предпоследнем разделе. В большинстве наших примеров используются одиночные имена, а не QName. Эти примеры реалистичны, поскольку XQuery обеспечивает способ указания пространства имен для запроса по умолчанию. Этот подход позволяет не использовать в запросах QName, если не нужно ссылаться на имена из других пространств имен.

Конструкторы элементов. Выражения пути — мощное средство, но им свойственно существенное ограничение: они способны выбирать только существующие узлы. В полном языке запросов необходимо наличие средства конструирования новых элементов и атрибутов, а также возможность указания их информационного наполнения и взаимосвязи. Это обеспечивается в XQuery с помощью вида выражения, называемого конструктором элементов (element constructor).

Простейший конструктор элементов создает элемент в полном соответствии с синтаксисом XML. Например, следующее выражение конструирует элемент с именем highbid, имеющий атрибут status и два элемента-потомка с именами itemno и bid-amount.

<highbid status = "pending">
<itemno>4871</itemno>
<bid-amount>250.00</bid-amount>
</highbid>

В этом примере значения элементов и атрибутов — константы. Однако во многих случаях необходимо создавать элемент или атрибут, значением которых является вычисляемое выражение. Выражение, заключенное в фигурные скобки, необходимо вычислить, а не трактовать как символьный текст. В конструкторе элемента это выражение вычисляется и заменяется своим значением. В следующем примере значения элементов и атрибутов вычисляются. Переменные $s, $i и $bids, используемые в этих выражениях, должны быть связаны с некоторыми выражениями.

<highbid status = "{$s}">
<itemno> {$i} </itemno>
<bid-amount>
{max($bids[itemno = $i]/bid-amount)}
</bid-amount>
</highbid>

В следующем примере конструктор элементов содержит выражение, заключенное в фигурные скобки, которое генерирует один атрибут и два подэлемента. Переменная $b должна быть связана с некоторым выражением.

<highbid>
{
$b/@status
$b/itemno
$b/bid-amount
}
</highbid>

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

В приведенных примерах конструкторов элементов, хотя содержимое элементов может быть вычисляемым, имя конструируемого элемента — известная константа. Однако иногда необходимо сконструировать элемент, имя которого, как и его содержимое, вычисляется. Для этого в XQuery определяется специальный вид конструктора, называемого вычисляемым конструктором элемента (computed element constructor). Он состоит из ключевого слова element, за которым следуют два выражения в фигурных скобках — первое вычисляет имя элемента, а второе — его содержимое.

Чтобы привести пример использования вычисляемого конструктора, предположим, что переменная $e связана с элементом, имеющим числовое значение. Нам нужно сконструировать новый элемент, имеющий то же имя, что и $e, и те же атрибуты, что у $e, но его значение должно быть вдвое больше значения $e. Этого можно добиться с помощью выражения, в котором функция data используется для получения числового значения исходного узла.

element
{name($e)}
{$e/@*, data($e)*2}

Подобно вычисляемому конструктору элемента, в XQuery обеспечивается вычисляемый конструктор атрибута (computed attribute constructor), состоит из ключевого слова attribute, за которым следуют два выражения в фигурных скобках — первое вычисляет имя атрибута, а второе — значение. Конструктор атрибута может использоваться везде, где допустим атрибут. Следующий конструктор атрибута на основе связанной переменной $p мог бы сгенерировать атрибут, который выглядит как father = или mother = .

attribute
{if $p/sex = "M" then "father" else "mother"}
{$p/name}

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

В наиболее простой форме итерация в XQuery задается оператором for, в котором указывается имя переменной и предоставляется последовательность значений, над которой переменная итерируется. Далее указывается оператор return, который содержит выражение, вычисляемое для каждого связывания переменной; см. ниже.

for $n in (2, 3) return $n + 1

Результатом этого итеративного выражения будет последовательность (3, 4).

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

for $m in (2, 3), $n in (5, 10)
return <fact>{$m} times {$n} is
{$m * $n} </fact>

В результате получается следующая последовательность из четырех элементов.

<fact>2 times 5 is 10 </fact>
<fact>2 times 10 is 20 </fact>
<fact>3 times 5 is 15 </fact>
<fact>3 times 10 is 30 </fact>

Операторы for и let — частные случаи более общего выражения, называемого FLWR. В наболее общем виде выражение FLWR может иметь несколько операторов for, несколько операторов let, необязательный оператор where, а также оператор return. Функция операторов for и let — связывание переменных. Каждый из них содержит одну или несколько переменных и выражение, присваиваемое каждой переменной. Результатом вычисления выражений являются последовательности, и выражения могут содержать ссылки на переменные, для которых связывание было выполнено в предыдущих операторах. Оператор for итерирует каждую переменную над ассоциированной с ней последовательностью, связывая переменную по очереди с каждым объектом последовательности, а как оператор let связывает каждую переменную сразу со всей ассоциированной последовательностью. Это различие иллюстрируется следующей парой операторов.

for $i in (1 to 3)
let $j := (1 to $i)

Эта пара операторов не является полным выражением FLWR, поскольку в нем отсутствует условие return. Операторы for и let просто порождают последовательность кортежей связываний. Приведенный выше пример порождает следующую последовательность из трех пар связываний.

$i = 1, $j = 1
$i = 2, $j = (1,2)
$i = 3, $j = (1,2,3)

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

Кортежи связывания, порожденные операторами for и let в FLWR-выражении, фильтруются в соответствии с необязательным условием where. Оператор where содержит выражение, которое вычисляется для каждого кортежа связывания. Если значением выражения where являются булевское значение true или непустая последовательность (<проверка существования>), то кортеж связываний принимается; в противном случае он отвергается.

Затем в выражении FLWR вычисляется оператор return по очереди и по одному разу для каждого оставшегося после проверки условия where кортежа связывания. Результаты вычислений объединяется в последовательность, которая и является результатом выражения FLWR.

Возможности FLWR иллюстрируются в запросе к базе данных аукциона Q4.

(Q4) Для каждого товара, который имеет более десяти ставок, создать элемент popular-item, содержащий номер товара, описание и число ставок.

for $i in
 document("items.xml")/*/item
let $b := document("bids.xml")
/*/ bid[itemno = $i/itemno]
where count ($b) > 10
return
<popular-item>
{
$i/itemno,
$i/description,
<bid-count> {count
 ($b)}</bid-count>
}
</popular-item>

Операторы for и let порождают пару связывания для каждого item в items.xml. В каждой паре связывания $i связан с товаром, а $b — с последовательностью, содержащей все ставки для этого товара. Оператор where оставляет только те связанные кортежи, в которых $b содержит более десяти ставок. Затем оператор return для каждого из этих связываний генерирует выходной элемент, содержащий номер товара, описание и число ставок.

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

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

Условие sortby часто полезно для переупорядочивания результатов выражения FLWR. Если необходимо отсортировать по убыванию bid-count элементы popular-item, сгенерированные в запросе Q4, то в конец Q4 можно добавить следующий оператор.

sortby bid-count descending

Важно понимать, что sortby не является частью выражения FLWR, а представляет собой отдельный вид выражений XQuery, который может использоваться для переупорядочивания любой последовательности, вне зависимости от того, сгенерирована она выражением FLWR или нет. Однако если после выражения FLWR стоит sortby, интеллектуальный оптимизатор поймет, что переупорядочивание выходных объектов снимает обычные ограничения на порядок кортежей связываний.

Q4 показывает, как выражение FLWR может походить на запрос с соединением в системе управления реляционной базой данных, а также на запрос с группировкой. Q4 похож на запрос с соединением, поскольку в нем коррелируются элементы, находящиеся в двух разных файлах — items.xml и bids.xml. Он также напоминает запрос с группировкой, поскольку ставки группируются по номеру товара, и вычисляется число ставок в каждой группе.

Арифметика. В XQuery обеспечиваются обычные арифметические операции: +, — , *, div и mod, а также агрегатные функции sum, avg, count, max и min, которые применяются к последовательности чисел и возвращают числовой результат. Оператор деления в XQuery называется div, чтобы его можно было отличить от слэша. Если после оператора вычитания следует имя, перед ним должен стоять пробел, который позволяет отличить его от дефиса, поскольку в XML дефис — корректный символ для имени.

Арифметические операции определяются для числовых значений. К числовым значениям относятся значения типов integer, decimal, float, double или типов, производных от них. Если типы операндов арифметической операции различны, операнды приводятся к ближайшему общему типу в соответствии с иерархией приведения integer -> decimal -> float -> double. Если операнд арифметического оператора является узлом, то автоматически извлекается его типизированное значение.

Важный частный случай — применение арифметических операций к пустым последовательностям. В XQuery пустая последовательность иногда используется для представления отсутствующей или неизвестной информации, во многом подобно тому, как неопределенное значение используется в реляционных системах. По этой причине операции +, -, *, div и mod определяются таким образом, что они возвращают пустую последовательность, если любой из операндов — пустая последовательность. Для иллюстрации этого правила предположим, что переменная $emps связана с последовательностью элементов emp, каждый из которых представляет сотрудника и содержит элементы name и salary, а также дополнительные элементы comission и bonus. Выражение в Q5 преобразует эту последовательность в последовательность элементов emp, каждый из которых содержит элементы name и pay, причем значение pay равно полной заработной плате сотрудника. Для тех сотрудников, комисионные (commission) или премия (bonus) которых не заданы ($e/commission или $e/bonus — пустая последовательность), генерируемый элемент pay будет пустым.

(Q5) Задана последовательность элементов emp. Заменить их подэлементы salary, commission и bonus на новый элемент pay, содержащий сумму значений исходных элементов, а результирующую последовательность отсортировать по убыванию значений элемента pay.

for $e in $emps
return
<emp>
{
$e/name,
<pay> {$e/salary + $e/commission
+ $e/bonus} </pay>
}
</emp>
sortby (pay)

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

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

Операторы union, intersect и except возвращают последовательность узлов в порядке документа и удаляют дубликаты из получившихся последовательностей с учетом индивидуальности узлов. Запрос Q6 является примером использования оператора intersect.

(Q6) Создать новый элемент с именем recent-large-bids, содержащий копии всех элементов bid документа bids.xml, которые имеют bid-amount со значением больше 1000 и bid-date со значением позже 1 января 2002 года.

<recent-large-bids>
document("bids.xml")
/*/ bid [bid-amount > 1000.00]
intersect
document("bids.xml")
/*/ bid [bid-date >
 date("2002-01-01")]
</recent-large-bids>

Выражения, в которых используются операции union, intersect и except, часто можно представить в другом виде. Так, запросу Q6 эквивалентен следующий запрос.

<recent-large-bids>
document("bids.xml")/*/bid
[bid-amount > 1000.00 and bid-date
> date("2002-01-01")]
</recent-large-bids>

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

document("items.xml")//itemno
except
document("bids.xml")//itemno

В этом запросе операция except применяется к двум последовательностям узлов itemno. Поскольку последовательности узлов выбираются из различных документов, ни один узел во второй последовательности не может быть идентичен узлу из первой последовательности. Результатом запроса будет последовательность всех узлов itemno документа items.xml. Если предполагалось с помощью этого запроса получить список элементов itemno для товаров, которые не имеют ставок, то можно добиться этого воспользовавшись библиотечной функцией empty, которая возвращает true, если ее операнд — пустая последовательность.

for $i in document("items.xml")//item
where empty(document("bids.xml")
//bid [itemno eq $i/itemno])
return $i/itemno

В этом примере предикат itemno eq $i/itemno сравнивает два узла itemno, извлекая и сравнивая их содержимое, а не проверяя их идентичность.

Операция |, оставленная для совместимости с XPath 1.0, эквивалентна операции union. Эти операции иногда применяются в шагах выражения пути. Например, следующее выражение пути находит объединение всех потомков b и потомков c узлов в последовательности, связанной с $a; узлы в этом объединении затем используются в качестве контекстных узлов для следующего шага в пути.

$a/(b | c)/d

Условные выражения. Условные выражения обеспечивают возможность выполнения одного из двух выражений в зависимости от значения третьего выражения. Это записывается в знакомом формате if…then…else, поддерживаемом во многих языках. Требуется наличие всех трех условий (if, then и else), а выражение в условии if должно быть заключено в скобки. Результат всего условного выражения зависит от значения выражения в условии if, называемого выражением проверки (test expression). Правила таковы.

Если значением выражения проверки являются булевское значение true или непустая последовательность (используемая как <проверка существования>), то выполняется оператор then.

Если значением выражения проверки являются булевское значение false или пустая последовательность, то выполняется оператор else.

В противном случае условное выражение возвращает значение ошибки.

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

if ($part/@discounted) then $part/wholesale
else $part/retail

Q7, представленный на Рис. 3, — пример более сложного запроса, содержащего условное выражение. Этот запрос также иллюстрирует несколько уровней вложенности выражений FLWR и конструкторов элементов.

Рис.3.

Q7) Создать отчет, описывающий состояние 
ставок для различных товаров. 
Пометить каждую ставку статусом <OK,> <too 
small> или <too late>. 
Поместить отчет в элемент с именем bid-status-report.

<bid-status-report>
 for $i in document (<items.xml>)/*/item
  return
 	<item>
	{
      $i/itemno,
         for $b in document (<bids.xml>)/*/bid[itemno = $i/itemno]
        return
	  <bid>
	  {
	  $b/bidder,
	  $b/bid-amount,
	  <status>
	  {
	   if ($b/bid-date > $i/end-date) then <too late>
	     else if ($b/bid-amount < $i/reserve-price)
	    then <too small>
	   else <OK>
	  }
	</status>
		}
	</bid>
	}
 </item>
</bid-status-report>

Кванторные выражения. Кванторные выражения позволяют проверить некоторое условие, устанавливая, истинно ли оно для некоторого значения последовательности (называется квантором существования) или для всех значений последовательности (называется квантором всеобщности). Результатом всегда является true или false.

Как и FLWR-выражение, кванторное выражение позволяет переменной выполнять итерацию над объектами в последовательности; выполняется поочередное связывание этой переменной с каждым элементом последовательности. Для каждого связывания переменной вычисляется проверочное выражение. Кванторное выражение, которое начинается с some, возвращает значение true, если выражение проверки истинно для некоторого связывания переменной.

some $n in (5,7,9,11) 
satisfies $n > 10

Кванторное выражение, начинающееся с every, возвращает значение true, если выражение проверки истинно для всех связываний переменной. Например, следующее кванторное выражение возвращает значение false, поскольку выражение проверки истинно не для всех связываний.

every $n in (5,7,9,11) 
satisfies $n > 10

Использование кванторных выражений иллюстрируется запросом Q8.

(Q8) Найти товары в items.xml, для которых все полученные ставки более чем вдвое превысили начальную цену. Получить копии всех таких элементов item, и поместить их в новый элемент с именем underpriced-items.

<underpriced items>
for $i in document("items.xml")
where every $b in document("bids.xml")
/*/bid [itemno = $i/itemno]
satisfies $b/bid-amount
> 2 * $i/reserve-price
return $i
</underpriced-items>

Функции

В XQuery предусмотрена библиотека предопределенных функций [11], а также предоставляется возможность определения пользователями их собственных функций. При вызове аргументы связываются с параметрами функции, и выполняется ее тело, порождая результат вызова функции. Если тип параметра функции не указан, этот параметр может принимать значения любого типа. Если не указан тип результата функции, то функция может возвращать значение любого типа.

В следующем примере определена функция с именем highbid, в качестве параметра использующая узел-элемент и возвращающая десятичное значение. Функция интерпретирует свой параметр как элемент item и извлекает номер товара. Затем она находит и возвращает самую крупную ставку (bid-amount), которая была зафиксирована для товара с этим номером.

define function highbid(element $item)
returns decimal
{
max(document("bids.xml")
//bid [itemno = $item/itemno]/bid-amount)
}
highbid(document("items.xml")
//item [itemno = "1234"])

Типы, используемые при объявлении типов аргументов и результата в определении функции, могут быть простыми, как decimal, или более сложными типами, например, элементами или атрибутами.

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

Аргументы при вызове функции должны соответствовать объявленным типам параметров функции. С этой целью аргумент функции числового типа может быть приведен к объявленному типу параметра с помощью иерархии приведения integer -> decimal -> float -> double. Аргумент также считается удовлетворяющим условию вызова, если тип этого аргумента является производным типом (т.е. подтипом) объявленного типа параметра. Если функция, ожидающая атомарное значение в качестве параметра, вызывается с аргументом, являющимся элементом, то до передачи аргумента функции из него извлекается типизированное значение элемента и проверяется на совместимость с ожидаемым типом параметра. Значение, производимое телом функции, должно также соответствовать возвращаемому типу, объявленному в определении; используются обычные правила проверки соответствия типов параметров.

Следующий пример иллюстрирует, как пользователь может написать функцию, которая предоставляет значение по умолчанию для отсутствующих данных. Функция с именем defaulted принимает два параметра: узел-элемент (возможно, отсутствующий) и значение по умолчанию. Если элемент присутствует и имеет непустое значение, функция возвращает это значение. Если же элемент отсутствует или пуст, функция возвращает значение по умолчанию.

define function defaulted
(element? $e, anySimpleType $d)
returns anySimpleType
{
if (empty($e))then $d
else if (empty($e/_)then $d
else data($e)
}

С помощь этой функции запрос Q5 можно переписать (здесь отсутствующие или пустые элементы commission и bonus считаются равными нулю).

for $e in $emps
return
<emp>
{
$e/name,
<pay> | {$e/salary
+ defaulted ($e/commission,0)
+ defaulted ($e/bonus,0)}
</pay>
}
</emp>
sortby(pay)

Функция, в теле которой присутствует вызов самой себя, называется рекурсивной (recursive), и две функции, в теле каждой из которых присутствует вызов другой функции пары, называются взаимно рекурсивными (mutually recursive). В следующем примере рекурсивная функция depth может быть вызвана для элемента и возвращает глубину элемента в иерархии, начинающейся с аргумента вызова. Если у элемент-аргумента отсутствуют потомки, глубина иерархии равна единице. Иначе глубина иерархии на единицу больше максимального значения глубины всех иерархий, корнем которых является потомок элемента-аргумента. Это значение вычисляется путем рекурсивного вызова функции depth.

define function depth(element $e)
returns integer
{
if (empty($e/*)) then 1
else 1 + max
(for $c in $e/* return depth($c))
}
depth(document("bids.xml"))

Типы

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

Один из способов сослаться на тип — это указать его квалифицированное имя, или QName. QName может указывать на встроенный тип, такой как xs:integer, или на тип, который определен в некоторой схеме, такой как abc:address. Если в QName имеется префикс пространства имен (часть, расположенная слева от двоеточия), этот префикс должен быть привязан к некоторому идентификатору пространства имен. Это связывание достигается путем описываемого в следующем разделе объявления пространства имен в прологе запроса.

Еще один способ сослаться на тип — сделать это с помощью родового ключевого слова, такого как element или attribute. За этим ключевым словом может следовать QName, которое в большей степени ограничивает имя или тип узла. Например, element обозначает любой элемент, element shipto — любой элемент с именем shipto; и element of type abc:address означает элемент, тип которого — address, объявленный в пространстве имен abc. Ключевое слово attribute обозначает любой атрибут, node — любой узел, а item — любой объект (узел или атомарное значение).

В XQuery также предусмотрен дополнительный синтаксис, который позволяет ссылаться на другие виды узлов и на типы элементов, которые определены в локальной части схемы. Например, element city in customer/address указывает на элемент с именем city, как это определено в контексте схемы customer/address.

За ссылкой на тип может следовать один из трех индикаторов присутствия: <*> означает <ноль или больше>, <+> означает <один или больше>, а означает <ноль или один>. Отсутствие индикатора присутствия означает присутствие ровно одного экземпляра указанного типа. Проиллюстрируем использование индикаторов присутствия.

element memo? означает возможное появление элемента с именем memo
element of type order+ означает один или несколько элементов с типом order
element* означает любое число любых элементов
attribute? означает необязательный атрибут с любым именем и типом

Ссылки на тип появляются не только в определениях функции, но и других местах. Одно из таких мест — второй операнд операции instance of, которая возвращает true, если ее первый операнд является экземпляром типа, указанного во втором операнде. Следующие примеры иллюстрируют использование операции instance of (предполагается, что префикс xs привязан к пространству имен схемы http://www.w3.org/2001/XMLSchema).

49 instance of xs:integer возвращает true
«Hello» instance of xs:integer возвращает false
<partno>369</partno> instance of element* возвращает true
$a instance of element shipto возвращает true, если $a привязана к элементу с именем shipto

Первая часть typeswitch состоит из выражения, тип которого проверяется (выражение операнда, operand expression), и необязательной переменной, связываемой со значением выражения операнда. Далее следуют одно или несколько операторов case, каждый из которых содержит тип и выражение. Операнд выражения по очереди проверяется на соответствие типу, указанному в каждом из условий case. Первый оператор case, для которого операнд выражения является экземпляром заданного типа, называется действующим случаем (effective case); выражение в этом операторе case вычисляется и служит результатом typeswitch. Если выражение операнда не соответствует ни одному из типов, указанных в условиях case, результат typeswitch берется из последнего оператора, действующего по умолчанию.

Проиллюстрируем использование typeswitch. Это выражение может появиться в цикле, где переменная $customer итерируется над множеством элементов customer, каждый из которых имеет подэлемент с именем billing-address. Подэлементы billing-address могут относиться к нескольким различным типам, каждый из которых требуется обрабатывать особым образом. Переменная $a связывается с billing-address, а затем вычисляется одно из нескольких выражений, в зависимости от динамического типа $a. В каждом операторе case $a имеет особый тип, например, в первом условии case типом $a должен быть element of type USAddress. Если выясняется, что элемент billing-address не соответствует ни одному из ожидаемых типов, результатом выражения является .

typeswitch ($customer/billing-address) as $a
case element of type USAddress
return $a/state
case element of type CanadaAddress
return $a/province
case element of type JapanAddress
return $a/prefecture
default return "unknown"

Имена типов также используются в трех внешне похожих выражениях XQuery, называемых cast, treat и assert. Каждое из этих выражений содержит ключевое слово, ссылку на тип и выражение, заключенное в скобки.

Выражение cast служит для преобразования результата выражения к одному из встроенных типов XML Schema. Поддерживается предопределенный набор преобразований. Например, результат выражения $x div 5 может быть приведен к типу xs:double с помощью выражения cast as xs:double($x div 5). В случае неудачного выполнения операция приведения типа может вернуть значение ошибки. Например, выполнение cast as xs:integer($mystring) будет успешным, если $mystring — строковое представление integer, но вернет ошибку, если $mystring имеет значение . Выражение cast не может использоваться для приведения значения к типу, определенному пользователем; для этого ему следует написать специальную функцию.

Выражение treat позволяет гарантировать, что динамический (времени исполнения) тип выражения соответствует предполагаемому типу. Например, предположим, что статическим(времени компиляции) типом выражения $customer/shipping-address является Address. Некоторое подвыражение может иметь смысл только для значений, соответствующих подтипу Address, такому как USAddress. Создатель подвыражения может использовать выражение treat для объявления ожидаемого типа подвыражения.

treat as USAddress($customer/billing-address)

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

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

$customer/billing-address/zipcode

Компилятор XQuery, проверяющий типы, мог бы решить, что в этом примере имеется ошибка типа, поскольку статическим типом $customer/billing-address является Address, а тип Address, в общем случае, не имеет подэлемента zipcode. Однако в следующей формулировке статический тип выражения меняется на USAddress, у которого есть подэлемент zipcode, и ошибка типа исчезает.

(treat as USAddress
($customer/billing-address))/zipcode

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

В следующем примере будет генерироваться ошибка типа времени компиляции, если статическим типом $customer/billing-address является Address.

(assert as USAddress
($customer/billing-address))/zipcode

В XQuery не требуется, чтобы в реализации поддерживалась статическая проверка типов. Для процессора запросов, который не обеспечивает статическую проверку, assert эквивалентно treat.

Проверка корректности

Процесс проверки корректности по схеме определен в [3]. Она может выполняться применительно к документу XML или к части документа, например, отдельному элементу.

В запросной модели данных с каждым узлом-элементом ассоциируется аннотация типа. Аннотация типа свидетельствует о том, что данный элемент прошел проверку на соответствие определенному заявленному типу. Элементы, которые не прошли проверку или не соответствуют заявленному типу, получают аннотацию родового типа anyType. Например, элемент, создаваемый конструктором элементов, имеет аннотацию anyType до тех пор, пока не получит более конкретный тип с помощью выражения validate. Ниже конструируется элемент и проверяется в соответствии со схемой (схемами), которые указываются в прологе запроса.

validate {<shipto>
<street>123 Elm St. </street>
<city>Elko, NV</city>
<zipcode>85039</zipcode>
</shipto>}

Аннотация типа используется в выражениях, проверяющих тип элемента, таких как instance of и typeswitch, и в выражениях, требующих элемента конкретного типа, таких как вызовы функций. Так, проверка элемента shipto может присвоить ему аннотацию типа USAddress, которая может позволить использовать его в качестве аргумента вызова функции, типом параметра которой является element of type USAddress.

Структура запроса

В XQuery запрос состоит из двух частей, называемых прологом запроса (query prolog) и телом запроса (query body). Пролог состоит из серии объявлений, которые определяют среду для обработки тела. Тело запроса — просто выражение, чье значение определяет результат запроса.

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

В объявлении пространства имен определяется префикс пространства имен и указывается его привязка к URI пространства имен. Префикс может быть любым идентификатором. В следующем объявлении пространства имен определяется префикс xyz и указывается его привязка.

namespace xyz
= "http://www.xyz.com/example/names"

Это объявление позволяет использовать префикс xyz в именах QName в теле запроса. Префикс связывается с URI некоторого пространства имен и служит в качестве уникального квалификатора для имен элементов, атрибутов и типов. Например, xyz:billing-address может уникально идентифицировать элемент billing-address, определенный в пространстве имен http://www.xyz.com/example/names. С одним пространством имен можно связать несколько префиксов.

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

default element namespace
= "http://www.xyz.com/example/names"
default function namespace
= "http://www.xyz.com/example/functions"

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

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

В схеме набор элементов, атрибутов и типов обычно определяется в некотором пространстве имен, называемом целевым пространством имен (target namespace) схемы, но префикс пространства имен не определяется. Поэтому при импорте схемы можно указать префикс пространства имен, привязанный к целевому пространству имен этой схемы. В следующем объявлении импорта схемы префикс пространства имен xhtml связывается с целевым пространством имен некоторой схемы, а также системе предоставляется отдельная <подсказка>, позволяющая найти эту схему.

schema namespace xhtml
= "http://www.w3.org/1999/xhtml"
at "http://www.w3.org/1999/xhtml/xhtml.xsd"

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

Выводы

XQuery определяется в терминах модели данных, основанной на неоднородных последовательностях узлов и атомарных значениях. Экземпляр этой модели данных может содержать один или несколько документов или фрагментов документов XML. Запрос обеспечивает отображение одного экземпляра модели данных на другой экземпляр. Запрос состоит из пролога, который устанавливает среду обработки, и выражения, которое генерирует результат запроса.

В настоящее время XQuery определен на уровне предварительных рабочих документов; созданием языка продолжает заниматься W3C XML Query Working Group. Эта рабочая группа активно обсуждает систему типов XQuery и вопрос о взаимном отображении этой системы типов и системы типов XML Schema. Также обсуждаются функции полнотекстового поиска, сериализация результатов запроса, обработка ошибок и ряд других вопросов. Скорее всего, окончательная спецификация XQuery будет включать в себя несколько уровней соответствия; например, в ней может быть определено, как следует производить статическую проверку типов, но не будет требоваться, чтобы она выполнялась в каждой реализации, соответствующей спецификации. Также ожидается, что подмножество XQuery будет объявлено как XPath версии 2.0, и станет возможным встраивание этого подмножества в другие языки, такие как XSLT [5].

Более полное описание XQuery и его грамматику в форме Бекуса-Науэра можно найти в [7]. Язык продолжает развиваться, поэтому спецификация XQuery может измениться.

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

Литература
  1. Extensible Markup Language 1.0 (Second Edition), W3C Recommendation (6 October 2000), http://www.w3.org/TR/REC-xml.
  2. World Wide Web Consortium, http://www.w3.org.
  3. Schema, Parts 0, 1, and 2, W3C Recommendation (2 May 2001), http://www.w3.org/TR/xmlschema-0, http://www.w3.org/TR/xmlschema-1 and http://www.w3.org/TR/xmlschema-2.
  4. Path Language Version 1.0, W3C Recommendation (1999 16 November), http://www.w3.org/TR/xpath.
  5. Transformation Version 1.0, W3C Recommendation (1999 16 November), http://www.w3.org/TR/xslt.
  6. XML Query Working Group, http://www.w3.org/XML/Query.
  7. XQuery 1.0: An XML Query Language, W3C Working Draft (2002 16 August), http://www.w3.org/TR/xquery.
  8. Query Requirements, W3C Working Draft (15 February 2001), http://www.w3.org/TR/xmlquery-req.
  9. XQuery 1.0 and XPath 2.0 Data Model, W3C Working Draft (2002 16 August ), http://www.w3.org/TR/query-datamodel.
  10. XQuery 1.0 Formal Semantics, W3C Working Draft (2002 16 August), http://www.w3.org/TR/query-semantics.
  11. XQuery 1.0 and XPath 2.0 Functions and Operators, W3C Working Draft (2002 16 August), http://www.w3.org/TR/xquery-operators.
  12. XMLQuery Use Cases, W3CWorking Draft (16 August 2002), http://www.w3.org/TR/xmlquery-use-cases.
  13. D. Chamberlin, J. Robie, D. Florescu, «Quilt: An XML Query Language for Heterogeneous Data Sources», Lecture Notes in Computer Science, Springer-Verlag (2000 December)
  14. T. Atwood, D. Barry, J. Duhl, J. Eastman, G. Ferran, D. Jordan, M. Loomis, D. Wade, The Object Database Standard: ODMG-93, Release 1.2, R. G. C. Catell, Editor, Morgan Kaufmann Publishers, San Francisco, CA (1996).
  15. Information Technology-Database Language SQL, Standard No. ISO/IEC 9075, International Organization for Standardization (1999); New York.
  16. J. Robie, J. Lapp, D. Schach, XML Query Language, http://www.w3.org/TandS/QL/QL98/pp/xql.html.
  17. A. Deutsch, M. Fernandez, D. Florescu, A. Levy, D. Suciu, A Query Language for XML, http://www.research.att.com/_mff/files/final.html.
  18. S. Abiteboul, D. Quass, J. McHugh, J. Widom, J. Wiener, «The Lorel Query Language for Semistructured Data», International Journal on Digital Libraries 1, No. 1, 68-88 (1997 April), http://www-db.stanford.edu/_widom/pubs.html.
  19. Namespaces in XML, W3C Recommendation (1999 14 January), http://www.w3.org/TR/REC-xml-names.
  20. XML Path Language 2.0, W3C Working Draft (2001 20 December), http://www.w3.org/TR/xpath20.

Дон Чемберлин — сотрудник исследовательского центра IBM Almaden Research Center; известен как один из разработчиков языка SQL и автор двух книг по реляционным базам данных. Сейчас деятельность Чемберлина связана с технологиями реляционных баз данных, обработкой документов и XML. Он является представителем IBM в рабочей группе W3C XML Query Working Group и редактором спецификации XQuery.

Don Chamberlin, Xquery: An XML query language. IBM Systems Journal, Vol. 41, No. 4, 2002. Copyright 2002, International Business Machines Corporation. All rights reserved. Reprinted with permission.

Язык разметки XML с самого первого стандарта окружает пользователей компьютеров. Таблицы в Excel, выгрузки из интернет-магазинов, RSS-ленты с новостями — все это основано на XML. Хоть визуальное отображение отличается на устройствах и в программах, но в основе всегда лежит единый формат.

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

В этой статье разберем:

  • для кого может быть полезен XPath
  • базовые конструкции языка для поиска информации в XML
  • чем XPath отличается от CSS-селекторов при поиске в HTML
  • Синтаксис XPath
  • Отличия от CSS-селекторов
  • Кому нужен Xpath
  • Заключение

Синтаксис XPath

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

<?xml version="1.0" encoding="UTF-8"?>
<courses>
  <title>Курсы HTML и CSS (верстка)</title>
  <description>На курсах по верстке вы познакомитесь с основами HTML и CSS, научитесь верстать адаптивные страницы, работать с препроцессорами. Освоите современные технологии и инструменты, включая Flex, Sass, Bootstrap.</description>
  <course>
    <name>Основы современной верстки</name>
    <tags>HTML5, CSS, DevTools, верстка</tags>
    <duration value="9">9 часов</duration>
    <url lang="ru">https://ru.hexlet.io/courses/layout-designer-basics</url>
    <url lang="en">https://hexlet.io/courses/layout-designer-basics</url>
  </course>
  <course>
    <name>Основы верстки контента</name>
    <tags>CSS3, HTML5, Селекторы, Доступность, CSS Columns, CSS Units, Верстка</tags>
    <duration value="18">18 часов</duration>
    <url lang="ru">https://ru.hexlet.io/courses/css-content</url>
    <url lang="en">https://hexlet.io/courses/css-content</url>
  </course>
  <course>
    <name>Bootstrap 5: Основы верстки</name>
    <tags>Bootstrap 5, Адаптивность, HTML, CSS3</tags>
    <duration value="10">10 часов</duration>
    <url lang="ru">https://ru.hexlet.io/courses/bootstrap_basic</url>
    <url lang="en">https://hexlet.io/courses/bootstrap_basic</url>
  </course>
</courses>

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

Для тестирования результата подойдут такие онлайн-сервисы, как:

  • Code Beautify
  • XPather

Абсолютные пути

Самый простой запрос состоит из обращения к корневому элементу. Для этого достаточно выполнить запрос /courses. Нам вернется XML в почти таком же виде, что и в примере выше. Обратите внимание на строку <?xml version="1.0" encoding="UTF-8"?>. Она отличается, потому что элемент не внутри <courses>:

<courses>
  <title>Курсы HTML и CSS (верстка)</title>
  <description>На курсах по верстке вы познакомитесь с основами HTML и CSS, научитесь верстать адаптивные страницы, работать с препроцессорами. Освоите современные технологии и инструменты, включая Flex, Sass, Bootstrap.</description>
  <course>
    <name>Основы современной верстки</name>
    <tags>HTML5, CSS, DevTools, верстка</tags>
    <duration value="9">9 часов</duration>
    <url lang="ru">https://ru.hexlet.io/courses/layout-designer-basics</url>
    <url lang="en">https://hexlet.io/courses/layout-designer-basics</url>
  </course>
  <course>
    <name>Основы верстки контента</name>
    <tags>CSS3, HTML5, Селекторы, Доступность, CSS Columns, CSS Units, Верстка</tags>
    <duration value="18">18 часов</duration>
    <url lang="ru">https://ru.hexlet.io/courses/css-content</url>
    <url lang="en">https://hexlet.io/courses/css-content</url>
  </course>
  <course>
    <name>Bootstrap 5: Основы верстки</name>
    <tags>Bootstrap 5, Адаптивность, HTML, CSS3</tags>
    <duration value="10">10 часов</duration>
    <url lang="ru">https://ru.hexlet.io/courses/bootstrap_basic</url>
    <url lang="en">https://hexlet.io/courses/bootstrap_basic</url>
  </course>
</courses>

В качестве результата XPath возвращает узлы XML-документа.

Продолжим цепочку и обратимся к описанию из элемента <description>. Для этого добавим в запрос путь к description: /courses/description. Результатом выполнения станет:

<description>На курсах по верстке вы познакомитесь с основами HTML и CSS, научитесь верстать адаптивные страницы, работать с препроцессорами. Освоите современные технологии и инструменты, включая Flex, Sass, Bootstrap.</description>

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

Попробуем обратиться к имени курса. В этом случае вернется поле <name> из всех курсов. Запрос /courses/course/name вернет:

<name>Основы современной верстки</name>
<name>Основы верстки контента</name>
<name>Bootstrap 5: Основы верстки</name>

Вот список некоторых базовых запросов и их результат:

Запрос          Результат                                                                               
/courses/course Все данные из всех элементов <course></course>                                         
/courses/course/name <name>Основы современной верстки</name>
<name>Основы верстки контента</name>
<name>Bootstrap 5: Основы верстки</name>
/courses/course/duration <duration value="9">9 часов</duration>
<duration value="18">18 часов</duration>
<duration value="10">10 часов</duration>

Относительные пути

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

Чтобы записать относительный путь, нужно использовать конструкцию //. После нее можно написать любое поле и получить результат. Например, //name вернет поля <name> из всего XML:

<name>Основы современной верстки</name>
<name>Основы верстки контента</name>
<name>Bootstrap 5: Основы верстки</name>

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

<courses>
  <title>Курсы HTML и CSS (верстка)</title>
  <!-- ... -->
    
  <course>
    <title>Основы современной верстки</title>
    <!-- ... -->
  </course>
    
  <course>
    <title>Основы верстки контента</title>
    <!-- ... -->
  </course>
    
  <course>
    <title>Bootstrap 5: Основы верстки</title>
    <!-- ... -->
  </course>
    
</courses>

Запрос //title вернет не только имена курсов, но и узел, который находится в <courses>:

<title>Курсы HTML и CSS (верстка)</title>
<title>Основы современной верстки</title>
<title>Основы верстки контента</title>
<title>Bootstrap 5: Основы верстки</title>

Чтобы сэкономить пару секунд, разработчики опускают корневой элемент и пользуются относительными путями. Например, вместо /courses/course/name они пишут //course/name. Для практики попробуйте прошлые примеры перевести на относительные пути с помощью такого механизма.

Несколько примеров запросов с идентичными ответами, как и в прошлой таблице:

Запрос              Результат                                                   
//course          Все данные из всех элементов <course></course>             
//name            <name>Основы современной верстки</name>
<name>Основы верстки контента</name>
<name>Bootstrap 5: Основы верстки</name>
//course/duration <duration value="9">9 часов</duration>
<duration value="18">18 часов</duration>
<duration value="10">10 часов</duration>

Предикаты

В примерах запросов к именам возвращались имена всех найденных курсов. В некоторых ситуациях это может быть избыточно. Что делать, если хочется получить данные только по первому курсу в <courses>? На помощь приходят предикаты — конструкции, с помощью которых можно отфильтровать элементы по заданным условиям. 

Выберем ключевые слова первого курса по верстке. Для этого достаточно использовать запрос //course[1]/tags:

<tags>HTML5, CSS, DevTools, верстка</tags>

Обратите внимание на[1]. Это предикат с таким условием: «Взять элемент по индексу 1». Попробуйте сделать запрос ко второму или третьему элементу. Достаточно поменять всего одну цифру! 


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


Предикаты помогают делать точные выборки. Например, получить ссылки на русскоязычные страницы курсов. Для этого нужно получить элементы <url>, у которых атрибут lang равен ru. Делается это указанием атрибута и значения. Чтобы XPath отличил атрибут от элемента перед атрибутом указывается символ @

Теперь запрос будет выглядеть так: //course/url[@lang="ru"]

<url lang="ru">https://ru.hexlet.io/courses/layout-designer-basics</url>
<url lang="ru">https://ru.hexlet.io/courses/css-content</url>
<url lang="ru">https://ru.hexlet.io/courses/bootstrap_basic</url>

Иногда полезно выбрать элементы, которые имеют хоть какой-то атрибут. Для этого можно использовать конструкцию //*[@*]:

<duration value="9">9 часов</duration>
<url lang="ru">https://ru.hexlet.io/courses/layout-designer-basics</url>
<url lang="en">https://hexlet.io/courses/layout-designer-basics</url>
<duration value="18">18 часов</duration>
<url lang="ru">https://ru.hexlet.io/courses/css-content</url>
<url lang="en">https://hexlet.io/courses/css-content</url>
<duration value="10">10 часов</duration>
<url lang="ru">https://ru.hexlet.io/courses/bootstrap_basic</url>
<url lang="en">https://hexlet.io/courses/bootstrap_basic</url>

По примеру выше видно, знак * обозначает «все/любой».

Когда выбраны элементы по атрибутам, можно произвести дополнительную фильтрацию по этим значениям. Например, найдем элементы <duration> со значением атрибута value больше 9. Внутри предикатов используются операторы сравнения, знакомые по языкам программирования:

  • > — больше
  • < — меньше
  • >= — больше или равно
  • <= — меньше или равно
  • = — равно
  • != — не равно

Запрос будет выглядеть так: //course/duration[@value > 9]:

<duration value="18">18 часов</duration>
<duration value="10">10 часов</duration>

Мы разобрались, как выбирать одно поле — это интересная, но редкая задача. Чаще разработчики обрабатывают данные по всему файлу или нескольким полям. Попробуем одновременно использовать предикат и обратиться к другим полям. Обратите внимание на два момента:

  • Предикат необязательно должен идти в конце запроса
  • Внутри предиката могут находиться новые пути, которые нужно проверить

Мы уже знаем, как с помощью предиката отфильтровать данные по полю <duration>. Эту задачу мы выполняли с помощью конструкции duration[@value > 9]. А теперь попробуем сделать эту конструкцию предикатом для <course>. Так мы получим данные о курсах с длительностью больше 9 часов: //course[duration[@value > 9]]:

<course>
  <title>Основы верстки контента</title>
  <tags>CSS3, HTML5, Селекторы, Доступность, CSS Columns, CSS Units, Верстка</tags>
  <duration value="18">18 часов</duration>
  <url lang="ru">https://ru.hexlet.io/courses/css-content</url>
  <url lang="en">https://hexlet.io/courses/css-content</url>
</course>
<course>
  <title>Bootstrap 5: Основы верстки</title>
  <tags>Bootstrap 5, Адаптивность, HTML, CSS3</tags>
  <duration value="10">10 часов</duration>
  <url lang="ru">https://ru.hexlet.io/courses/bootstrap_basic</url>
  <url lang="en">https://hexlet.io/courses/bootstrap_basic</url>
</course>

Можно продолжить этот запрос и получить только имена курсов. Тогда предикат будет в середине запроса, а не в его конце: `//course[duration[@value > 9]]/name

<name>Основы верстки контента</name>
<name>Bootstrap 5: Основы верстки</name>

Функции

В прошлых примерах запросы затрагивали теги и атрибуты. Сами данные мы не затрагивали, хотя это огромный пласт информации, по которой можно делать выборки. Для решения этой задачи используются встроенные в XPath функции. Они являются частью предикатов — например, @. Попробуем найти курс с названием «Основы верстки контента».

Для поиска по тексту внутри элемента используется функция text(). Ее задача — получить текстовое значение элемента и сравнить его с условием по необходимости. Вот как будет выглядеть запрос для поиска курса с нужным именем: //course[name[text()="Основы верстки контента"]]

<course>
  <name>Основы верстки контента</name>
  <tags>CSS3, HTML5, Селекторы, Доступность, CSS Columns, CSS Units, Верстка</tags>
  <duration value="18">18 часов</duration>
  <url lang="ru">https://ru.hexlet.io/courses/css:content</url>
  <url lang="en">https://hexlet.io/courses/css:content</url>
</course>

Но что, если нам известно только часть названия? Для этого существует функция contains(), которая принимает два аргумента:

  1. Строка, где будет производиться поиск
  2. Подстрока, которая будет искаться

Для примера найдем курс, у которого в ключевых словах есть слово «Bootstrap». Функция примет текстовое значение элемента tags и найдет там слово «Bootstrap»: //course[tags[contains(text(), "Bootstrap")]]

<course>
  <name>Bootstrap 5: Основы верстки</name>
  <tags>Bootstrap 5, Адаптивность, HTML, CSS3</tags>
  <duration value="10">10 часов</duration>
  <url lang="ru">https://ru.hexlet.io/courses/bootstrap_basic</url>
  <url lang="en">https://hexlet.io/courses/bootstrap_basic</url>
</course>

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

Отличия от CSS-селекторов

Если вы писали на JavaScript, то знаете, что элементы можно искать с помощью CSS-селекторов, используя методы querySelector() или querySelectorAll(). Почему же разработчики иногда ищут элементы внутри HTML именно с помощью XPath?

Дело в концепции поиска элементов. Используя CSS, можно идти только в глубину без возможности обратиться к родительским элементам. В отличие от CSS, XPath позволяет в любой момент обращаться и к дочерним, и к родительским элементам.


Если вы хотите подробнее изучить поиск по HTML с помощью XPath, рекомендуем обратиться к статье Introduction to using XPath in JavaScript.


С помощью CSS нельзя найти все элементы div, внутри которых есть ссылки — можно найти сами ссылки, но не их родителей. XPath позволяет это сделать простым сочетанием div[a]. Постепенно ситуация меняется: в CSS появился селектор :has(), но он поддерживается еще не всеми новыми версиями браузеров. Со временем это изменится, но пока реальность именно такая.

Другой пример — поиск элементов по тексту внутри них. С этой задачей CSS никогда не справится, так как такой цели у него нет. XPath, как мы изучили, умеет это делать с помощью функции text().

Кому нужен Xpath

Если коротко, Xpath нужен всем, кто работает с XML.

Чтобы разобраться подробнее, изучим несколько примеров:

SEO-специалисты. Специалисты по продвижению часто обрабатывают большие массивы данных и вытаскивают информацию со страниц сайта.

Например, для них критичны мета-теги — дополнительная информация, в которой содержатся иконки сайтов, название страницы, описание и так далее. Эту информацию SEO-специалист может автоматически парсить с помощью запросов в XPath.

Тестировщики. При работе с Front-end тестировщики часто проверяют тот или иной вывод информации на странице — для этого они выбирают отдельные элементы с нужной страницы. Это можно делать через XPath и DevTools, встроенный в браузеры на основе Chromium.

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

Это лишь часть сценариев, в которых пригождается язык XPath — на самом деле, их десятки.

Заключение

В этой статье мы рассмотрели, где встречается XML и кому он может пригодиться. Мы научились составлять базовые запросы и изучили часто используемые конструкции XPath:

  • Абсолютные и относительные пути
  • Предикаты
  • Поиск по атрибутам
  • Операторы сравнения
  • Функции

Также теперь вы знаете, что поиск по HTML с помощью XPath может быть эффективнее поиска с помощью CSS-селекторов.

В этой статье мы постарались дать знания, которые помогут справиться с большинством задач. Но это далеко не все возможности XPath — это более глубокий язык, чем представлено в статье. Как и с другими технологиями, тут важно набить руку. Чем больше вы практикуетесь, тем более точные и полезные запросы пишете.

Понравилась статья? Поделить с друзьями:
  • Как найти операторов у детей
  • Как найти сумму нескольких ячеек в excel
  • Как составить деловое письмо по русскому языку 8 класс
  • Как найти комплексный коэффициент передачи
  • Как найти наибольшее значение первообразной функции