Язык XPath является результатом попыток создать единые синтаксис и семантику для функционала, совместно используемого XSL Transformations [XSLT] и XPointer [XPointer]. Главная задача языка XPath - адресация частей в XML документе [XML]. Для достижения этой цели язык дополнительно наделен основными функциями для манипулирования строками, числами и булевыми значениями. В XPath используется компактный синтаксис, отличный от принятого в XML, облегчающий использование языка XPath при записи адресов URI и значений атрибутов XML. XPath работает не с внешним синтаксисом XML документа, а с его абстрактной логической структурой. XPath получил такое название потому, что использовался в URL для записи путей, обеспечивающих навигацию по иерархической структуре XML документа.

Язык XPath спроектирован так, что помимо поддержки адресации он обладает естественным набором элементов, которые могут использоваться для сравнения (проверки, соответствует ли узел некому шаблону). Такой порядок использования языка XPath описывается в спецификации XSLT. представляет XML документ в виде дерева узлов. Узлы бывают различных типов, например, узлы элементов, узлы атрибутов и узлы текста. Для каждого типа узлов в XPath определяется способ вычисления строкового значения. Некоторые типы узлов имеют также имя. XPath полностью поддерживает пространства имен XML [XML Names]. В результате, имя любого узла в этом языке образуется из двух частей: локальной части и URI некого пространства имен (возможно, нулевого), такая комбинация называется расширенным именем.

Главной синтаксической конструкцией языка XPath является выражение. Любое выражение соответствует сценарию Expr. В результате обработки выражения получается объект, относящийся к одному из четырех основных типов:

·набор узлов (node-set) - неупорядоченный набор узлов без дубликатов

·булево значение (boolean) - true или false

·число (number) - число с плавающей точкой

·строка (string) - последовательность UCS символов

Обработка выражений осуществляется, отталкиваясь от некого контекста. В спецификациях XSLT и XPointer указывается, каким образом в XSLT и XPointer, соответственно, определяется контекст для выражений XPath. Контекст образуется из:

·узла (узел контекста, context node)

·пары ненулевых положительных целых чисел (положение в контексте и размер контекста)

·привязки переменных контекста (variable bindings)

·библиотеки функций

·набора деклараций пространства имен в области видимости данного выражения

Положение в контексте всегда меньше или равно размеру контекста.

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

Библиотека функций образуется в результате отображения множества названий функций на множество функций. Каждая функция имеет нуль или более аргументов и возвращает один результат. В данном документе описывается основная библиотека функций, которую должны поддерживать все реализации XPath. Для любой функции в основной библиотеке и аргументы, и результат выполнения относятся к четырем основным типам. И XSLT, и XPointer дополняют XPath, определяя дополнительные функции, часть новых функций оперирует с четырьмя основными типами, остальные - дополнительными типами данных, определенными в XSLT и XPointer. Декларации пространства имен образуются в результате отображения множества префиксов на множество идентификаторов URI пространств имен.

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

Выражения XPath часто используются в атрибутах XML. Описываемая в этой главе грамматика примеряется к значению атрибута после выполнения нормализации, описанной в XML 1.0. Так, если, к примеру, в грамматике используется символ <, то в исходном XML документе его нельзя записывать просто как <. Вместо этого, согласно правилам XML 1.0, его необходимо маскировать, например, записав как &lt;. Строковые значения, используемые в выражениях, заключаются в одинарные или двойные кавычки, которые используются также для записи атрибутов XML. Поэтому, чтобы символ кавычки в этом выражении не интерпретировался XML процессором как конец значения атрибута, его необходимо записывать как ссылку на символ (&quot; или &apos;). Впрочем, если атрибут XML был заключен в двойные кавычки, в выражении можно свободно использовать символы одинарных кавычек, и наоборот.

Другим важным типом выражений является путь адресации (location path). Путь адресации выбирает некое множество узлов, отталкиваясь от некоторого узла контекста. Результатом обработки выражения, соответствующего пути адресации, является множество узлов, собранных согласно этому пути. Путь адресации может рекурсивно содержать выражения, используемые для фильтрации наборов узлов. Путь адресации соответствует сценарию LocationPath.

В представленной далее грамматике используются незавершенные конструктивы QName и NCName, описанные в [XML Names], а также пробельный символ S, описанный в [XML]. Грамматика использует ту же самую нотацию EBNF, что [XML] (за исключением того, что названия грамматических конструкций всегда пишутся с заглавной буквы).

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

Формирование запросов XPath

Абакан, 2009

XPath не рассчитан на работу с реляционными данными. Чтобы использовать XPath-запросы для выборки реляционных данных, необходимо создать схему данных XDR или XSD. XDR была разработана несколько лет назад при активном участии Microsoft, т.к. в то время необходимость в схемах данных была, а, по существу, самих схем не было. С появлением XSD популярность и актуальность применения XDR начали падать.

Схема данных выполняет две важные функции: задает структуру будущего XML-документа и определяет, какие поля и таблицы должны использоваться при выполнении запроса XPath. Такие схемы называются аннотированными схемами запросов, а атрибуты, связывающие объекты базы данных с XML-узлами - аннотациями. До выхода в свет SQLXML 2.0 можно было использовать только аннотированные схемы на основе SDR [6]. Однако сейчас лучше использовать аннотированные схемы на основе спецификации XSD [7]. Синтаксис шаблонов с использованием запросов XPath:

<your_root xmlns:sql="urn:schemas-microsoft-com:xml-sql">

<sql:header>

<xql:param name="your_param_name"> param_value </sql:param>

<xql:param name="your_param_name"> param_value </sql:param>...n

</sql:header>

<sql:xpath-query mapping-schema="your_schema.xml">query

</sql:xpath-query>

</your_root>

В этом примере аннотированная схема должна находится в файле your_schema.xml. Как видно из синтаксиса, возможно создание параметризированных запросов XPath. Параметр в запросе обозначается начальным символом $.

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

<?xml version="1.0" ?>

<Schema xmlns="urn:schemas-microsoft-com:xml-data":sql="urn:schemas-microsoft-com:xml-sql":dt="urn:schemas-microsoft-com:datatypes">

<ElementType name="address" />

<ElementType name="Authors" sql:relation="Authors">

<AttributeType name="au_fname" dt:type="string" />

<AttributeType name="au_lname" dt:type="string" />

<attribute type="au_fname"/>

<attribute type="au_lname" />

<element type="address" sql:field="address"/>

</ElementType>

</Schema>

Здесь используется аннотация relation для того, чтобы указать, с какой таблицей будет связан элемент Authors. Дочерние элементы наследуют связь с таблицей, указанной для родительского ElementType. Связывание полей таблицы или представления (view) можно выполнять явно, с использованием аннотации field. В данном примере для элементов AttributeType этого делать не нужно, т.к. отображения на соответствующие поля выполняются автоматически. Однако для дочерних элементов ElementType, которые по умолчанию связываются с таблицами, такая аннотация может быть необходима. Наиболее часто используемые аннотации приведены далее.

Теперь можно перейти к самому шаблону. Предположим, аннотированную схему вы сохранили под именем MySchema.xml.

Вот так выглядит шаблон, выбирающий имена, фамилии и адреса всех авторов:

<my_root xmlns:sql="urn:schemas-microsoft-com:xml-sql">

<sql:xpath-query mapping-schema="../Schema/MySchema.xml">

/Authors

</sql:xpath-query>

</my_root>

Так как схемы XDR постепенно вытесняются схемами XSD, перепишем пример с использованием XSD.

Вот список основных отличий XDR от XSD[9], к которому я очень часто обращаюсь:

XDR XSDschemaelementattributenone

С учетом этого схема будет выглядеть так:

<xsd:schema xmlns:xsd="#"justify">xmlns:sql="urn:schemas-microsoft-com:mapping-schema">

<xsd:element name="authors" sql:relation="authors">

<xsd:complexType>

<xsd:attribute name="au_fname" sql:field="au_fname" />

<xsd:attribute name="au_lname" sql:field="au_lname" />

<xsd:attribute name="address" sql:field="address" />

</xsd:complexType>

</xsd:element>

</xsd:schema>

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

<?xml version="1.0" encoding="windows-1251" ?>

<xsd:schema xmlns:xsd="#"justify"><xsd:element name="Авторы" sql:relation="authors">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Фамилия" sql:field="au_lname"/>

<xsd:element name="Адрес" sql:field="address" />

</xsd:sequence>

<xsd:attribute name="Имя" sql:field="au_fname"/>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Если схема находится в виртуальном каталоге, тип которого schema, вы можете выполнять XPath-запросы, непосредственно указывая их в URL. Результирующий документ может не иметь корневого элемента, поэтому не забывайте указывать параметр root.

://server/server_pubs/schema/xsd_map_schema.xml/Авторы?root=root

Вот другие аннотации, часто используемые в схемах:- элемент, обозначающий связь с соответствующими друг другу первичными и внешними ключами. Используется для построения иерархических XML-документов. constant - указывает, что соответствующий элемент не связывается с таблицей или колонкой базы данных. field - булева переменная, принимающая значение 0 или 1. Значение 0 указывает, что соответствующий элемент не будет присутствовать в результирующем документе. С выходом SQLXML 3.0 аннотация была переименована в mapped. field и limit-value - предназначены для указания поля и его значения, по которым будет фильтроваться запрос к базе данных. Результат использования этих аннотаций аналогичен ограничению результирующего набора строк с помощью оператора WHERE. cdata - указывает, что соответствующий XML-узел будет представлен в секции CDATA результирующего документа. Узел должен быть связан с полем таблицы или представления и не может применяться совместно с url-encode или ID, IDREF, IDREFS, NMTOKEN и NMTOKENS. - булева переменная, принимающая значение 0 или 1. Указывает на то, что соответствующий XML-узел будет скрыт (значение 0) в результирующем XML-документе, однако может быть использован в запросе XPath. Не путайте её с аннотацией mapped. Различие в том, что при помощи mapped XML-узел совсем исключается из документа, так что не может быть использован в запросе XPath.

Рассмотрим пример, демонстрирующий работу некоторых из перечисленных аннотаций. В разделе FOR XML EXPLICIT был составлен иерархический список издательств и служащих, которые в них работают. Попробуем получить такой же XML-документ с помощью аннотированной схемы:

<?xml version="1.0" ?>

<xsd:schema xmlns:xsd="#"justify">xmlns:sql="urn:schemas-microsoft-com:mapping-schema">

<xsd:annotation>

<xsd:appinfo>

<sql:relationship name="PubsEmployees"="publishers" parent-key="pub_id"="employee" child-key="pub_id" />

</xsd:appinfo>

</xsd:annotation>

<xsd:element name="pubs" sql:relation="publishers">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="employee":relation="employee":relationship="PubsEmployees" >

<xsd:complexType>

<xsd:attribute name="First_Name" sql:field="fname" ="xsd:string" />

<xsd:attribute name="Last_Name" sql:field="lname" ="xsd:string" />

<xsd:attribute name="minit" sql:field="minit" ="xsd:string" sql:hide="1" />

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="PubName" sql:field="pub_name" type="xsd:string"/>

<xsd:attribute name="City" sql:field="city" type="xsd:string" :limit-field="pub_name" sql:limit-value="Binnet &amp; Hardley" />

</xsd:complexType>

</xsd:element>

</xsd:schema>

Здесь использован атрибут hide для удаления XML-узла из результирующего документа, но сохранить возможность его использования в XPath-запросах. Атрибуты limit-field и limit-value ограничивают количество издательств одним - «Binnet & Hardley». Раздел xsd:annotation вынесен, однако его можно было использовать и внутри узла <xsd:element name="employee"…>. В таком случае имя элемента relationship можно было не указывать.

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

://server/server_pubs/schema/schema1.xml/pubs/employee[@minit=""]?root=root

Схемы можно непосредственно указывать в шаблоне. Например:

<?xml version="1.0" encoding="windows-1251" ?>

<my_root xmlns:sql="urn:schemas-microsoft-com:xml-sql">

<xsd:schema xmlns:xsd="#"justify"><xsd:element name="Авторы" ms:relation="authors">

<xsd:complexType>

<xsd:attribute name="Имя" ms:field="au_fname"/>

<xsd:attribute name="Фамилия" ms:field="au_lname"/>

<xsd:attribute name="Адрес" ms:field="address"/>

</xsd:complexType>

</xsd:element>

</xsd:schema>

<sql:xpath-query mapping-schema="#InLineSchema1">

/Авторы

</sql:xpath-query>

</my_root>

Для того чтобы запрос XPath использовал схему, а также для сокрытия ее в результирующем документе XML, указан атрибут is-mapping-schema. Он может принимать значения 0 или 1. Кроме этого, необходимо явно сослаться на используемую схему, так как их в шаблоне может быть несколько. Это делается путем добавления атрибута id в схему и атрибута mapping-schema - в раздел самого запроса.

Создание аннотированных схем не совсем тривиальная задача, требующая к тому же знания большого количества тонкостей. К счастью, в Microsoft разработали специальный инструмент для автоматической генерации схем - XML View Mapper. Его можно бесплатно скачать по адресу #"justify">К сожалению, SQL Server 2000 лишь частично поддерживает спецификацию XPath и возможности использования XPath-запросов к базе данных. Ниже приведена сводка поддерживаемых и не поддерживаемых возможностей.

Поддерживаемая функциональность XPath:

Не поддерживаемая функциональность:

В качестве простых запросов (query) могут выступать любые SQL-инструкции. Шаблоны могут быть использованы для изменения данных, хотя это и не лучшее решение. Другие методы изменения данных рассматриваются в разделе Апдейтаграммы и XML Bulk Load.

Использование запросов XPath

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

Таблица 3.

Файловая система (URL)XPathИерархия каталогов и файлов.Иерархия элементов и других узлов XML-документа.Файлы на каждом из уровней имеют уникальные имена. URL всегда идентифицирует один файл.Имена элементов на каждом уровне могут быть неуникальны. Шаблоны XPath соответствуют набору всех соответствующих элементов.Путь вычисляется относительно конкретного каталога, именуемого текущим каталогом.Путь вычисляется относительно конкретного узла, в запросе именуемого контекстом.

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

<authors>

<author>

<name>Victor Hugo</name>

<nationality>French</nationality>

</author>

<author period="classical">

<name>Sophocles</name>

<nationality>Greek</nationality>

</author>

<author>

<name>Leo Tolstoy</name>

<nationality>Russian</nationality>

</author>

<author>

<name>Alexander Pushkin</name>

<nationality>Russian</nationality>

</author>

<author period="classical">

<name>Plato</name>

<nationality>Greek</nationality>

</author>

</authors>

При исполнении XPath-запроса всегда имеется так называемый контекст исполнения, то есть текущая ветка, относительно которой производится поиск. Это сходно с активным каталогом при выполнении команды CD файловой системы. Как контекст XPath-запроса может использоваться любой узел XML-документа. В XSLT контекстом для запроса является узел, в данный момент обрабатываемый элементами <xsl:template> или <xsl:for-each>. При использовании XPath непосредственно из DOM вы определяете контекст, выполняя запрос из конкретного узла. Приведенные ниже примеры используют контекст корневого элемента XML-документа.

Основным понятием XPath является путь в XML-иерархии. Если выполнить приведенный ниже запрос, начиная с корневого элемента приведенного выше примера, этот запрос проходит по иерархии вплоть до элемента <name>.

authors/author/name

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

Кроме описания пути, XPath может включать wildcards (групповые символы). Элемент с любым именем обозначается символом "*".

authors/*/name

Предыдущий запрос соответствует всем элементам name, но не требует, чтобы они находились в элементе <author>. Вот еще один пример, находящий элементы <name> и <nationality>.

authors/author/*

Ветвления пути могут быть описаны с помощью квадратных скобок. Следующий запрос ищет ветку элемента <author>, и означает, что рассматриваться должны только элементы <author> с дочерним nationality.

authors/author[nationality]/name

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

authors/author[nationality='Russian']/name

XML-атрибуты в запросе обозначаются символом "@" перед именем атрибута. Атрибут может проверяться как ветка основного пути, но запрос может и целенаправленно искать узлы атрибутов. Следующий пример возвращает авторов классического периода.

authors/author[@period="classical"]

Таблица 4.Операторы и специальные символы Xpath

ОператорОписание/Выбирает дочерние элементы коллекции, находящейся слева от него. При использовании в начале шаблона означает поиск от корневого элемента.//Рекурсивный спуск; ищет указанный элемент на любой глубине. При использовании в начале шаблона означает рекурсивный поиск от корневого элемента..Текущий контекст.*Wildcard, выбирает все элементы, независимо от имени.@Атрибут; префикс имени атрибута. При использовании без имени атрибута выбирает все атрибуты, независимо от их имени.:Сепаратор пространств имен. Отделяет префикс пространства имен от имени элемента или атрибута.( )Группирует операции для явного задания очередности.[ ]Накладывает фильтр. 2. Используется для индексации коллекции+Сложение.-Вычитание.divДеление с плавающей точкой (согласно IEEE 754).*Умножение.modВозвращает остаток при делении с остатком.

Больше работ по теме: