Российские Электронные Библиотеки

XML и функциональное программирование

 

Д.А. Лизоркин
lizorkin@hotbox.ru

К.Ю. Лисовский
lisovsky@acm.org

Московский Государственный Университет
Институт Системного Программирования РАН

 

Оглавление

  1. Введение
  2. SXML: XML-документ как S-выражение
    1. XML, XML Information Set и SXML
    2. Спецификация SXML
    3. Свойства SXML
  3. Пространства имен в XML и SXML
    1. Пространства имен в XML
    2. Пространства имен в SXML
    3. Применение пространств имен в контексте электронных библиотек
      1. Dublin Core
      2. Представление Dublin Core в Модели Описания Ресурсов (RDF)
  4. Язык XML Path (XPath) и его функциональная реализация SXPath
    1. Обзор XPath
    2. SXPath: реализация языка XML Path на Схеме
    3. Низкоуровневые функции SXPath
    4. Высокоуровневые функции SXPath
  5. Язык XSLT и его реализация функциональными методами
    1. Обзор языка XSLT
    2. STX: реализация XSLT на Схеме
  6. Язык XLink и его реализация функциональными методами
    1. Обзор языка XLink
    2. Реализация XLink на Схеме: SXLink
    3. Функциональная интеграция XSLT и XLink
  7. Заключение
  8. Список литературы

     

1  Введение

Текстовые форматы представления слабоструктурированных данных, такие как SGML и XML, представляют текст как упорядоченную иерархическую структуру, что делает их крайне привлекательными в контексте электронных библиотек [1].

В настоящий момент "XML-революция" может считаться состоявшимся фактом, а стремительное развитие XML-технологий в течении последних лет затронуло практически все отрасли информатики. Электронные библиотеки (ЭБ) не являются здесь исключением, и XML рассматривается как одна из ключевых технологий для построения современных электронных библиотек [2].

Предлагаемые консорциумом W3C языки обработки XML-данных, такие как XPath, XSLT, XQuery и др., не являются языками программирования общего назначения и, как правило, недостаточны для реализации законченных приложений. Большинство XML-приложений реализуется при помощи традиционных языков программирования, таких как С или Java, или скрипт-языков, например Perl, JavaScript или Python.

Комбинирование двух различных по своей природе языков (например, XPath и Java) приводит к проблеме, известной как несоответствие импеданса (impedance mismatch). Данная проблема складывается из двух аспектов:

  • Различные модели данных. Например: XPath моделирует документ как дерево, в то время как большинство языков программирования общего назначения не предоставляют такого типа данных.
  • Различные вычислительные парадигмы. Так, XSLT является функциональным языком, тогда как Java объектно-ориентированным, а Perl - процедурным.

Несоответствие импеданса приводит к необходимости использовать сложные конвертеры и интерфейсы прикладного программирования (например, DOM) для комбинирования таких двух языков.

Несоответствия импеданса может быть значительно уменьшено и даже полностью устранено при использовании для задач обработки XML-данных функционального языка Схема (Scheme):

  • Вложенные списки (S-выражения) языка Схема являются естественным представлением вложенных элементов XML. Схема представляет свой код и данные в виде многоуровневых нетипизированных списков. XML-документ, являясь иерархией вложенных друг в друга XML-элементов, может быть представлен в виде подобного многоуровневого списка (который текстуально записывается при помощи так называемых S-выражений).
  • Схема является функциональным языком, как и большинство XML-языков (XSLT, XQuery). Схема обрабатывает многоуровневые списки рекурсивным способом, что может рассматриваться как обход/трансформация дерева документа.

Схема, диалект Лиспа, получила широкое признание как скрипт-язык [3]. Это один из самых лаконичных и компактных языков, применяемых на практике: описание стандарта языка Схема [4] состоит из 40 страниц. Это язык высокого уровня, пригодный для быстрого прототипирования. Программы на Схеме, как правило, в несколько раз короче эквивалентных программ на языке C.

2  SXML: XML-документ как S-выражение

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

2.1  XML, XML Information Set и SXML

XML-документ [5] имеет, в сущности, древовидную структуру. Открывающий и закрывающий теги корневого элемента заключают в себе все содержимое документа, которое может содержать другие элементы и произвольные символьные данные. Текст с парными угловыми скобками является внешним представлением XML-документа. Приложениям приходится работать с его внутренним представлением: информационным пространством (XML Information Set) или его специализированными разновидностями (такими как DOM). Такое внутреннее представление позволяет приложениям находить конкретную информацию или трансформировать XML-дерево в другое дерево.

Консорциум W3C определяет Информационное пространство XML Infoset [6] как абстрактное множество данных, которое описывает информацию, содержащуюся в правильном (well-formed) XML-документе. Информационное пространство документа состоит из информационных элементов (information items), которые обозначают элементы, атрибуты, символьные данные, команды по обработке и другие компоненты документа. Каждый информационный элемент имеет набор ассоциированных с ним свойств (properties), например, имя и идентификатор пространства имен. Значения некоторых свойств, например, "дочерний элемент" и "атрибут", -- представляют собой (упорядоченный) набор других информационных элементов. Хотя Infoset определен лишь для XML, он в значительной степени применим и для других слабоструктурированных форматов данных, в частности, HTML.

Разбор XML-документа является лишь одним из возможных способов получения набора информационных элементов XML Information Set.

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

Абстрактная модель XML-данных, определенная в рекомендации XML Information Set, применима к любой из XML-спецификаций консорциума W3C. Так, Document Object Model [7] может рассматриваться как интерфейс прикладного программирования (API) для работы с наборами информационных элементов XML Information Set; узлы модели данных XPath [8] могут быть получены из информационных элементов XML Information Set, и так далее. Модели данных DOM и XPath являются, таким образом, двумя конкретными реализациями XML Infoset.

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

Другая трактовка информационного элемента -- это интерпретация его в виде контейнера, содержащего свои свойства: текстовые строки (например, имя, идентификатор пространства имен) или другие контейнеры (например, дочерние элементы для XML-элемента). Информационное пространство в этом случае представляет собой иерархию вложенных друг в друга контейнеров. Как заметил Олег Киселев [9], подобная иерархия контейнеров, состоящих из текстовых строк и других контейнеров, очень хорошо поддается описанию в виде S-выражения; поскольку последнее определяется рекурсивно как список, члены которого -- либо атомарные значения, либо снова S-выражения. S-выражения [10] легко разбираются во внутреннее представление, подходящее для организации обхода; они также имеют простую внешнюю нотацию, которая может довольно просто составляться даже вручную.

SXML является конкретной реализацей XML Infoset в форме S-выражений. Задачей информационного пространства Infoset является представление в некоторой форме всех существенных единиц данных и их абстрактного соотношения друг с другом. SXML дает множеству контейнеров конкретную реализацию в виде S-выражений, и обеспечивает средства доступа к информационным элементам и их свойствам. SXML является "родственником" XPath и DOM, модели данных которых представляют собой две других реализации XML Infoset. Формат SXML особенно удобен для решения на Схеме таких задач как конструирование XML/HTML-документов, выполнение запросов языка XPath и трансформация деревьев.

Таким образом, XML и SXML могут рассматриваться как два синтаксически различных представления XML Information Set.

2.2  Спецификация SXML

SXML есть реализация XML Infoset в виде S-выражений. Дальнейшее рассмотрение SXML в данном подразделе основано на спецификации SXML [9].

Упрощенная грамматика SXML в нотации EBNF представлена на рисунке 1. Нетерминал <name> -- это одиночный символ языка Схема.


[1] <TOP> ::= ( *TOP* <PI>* <Element> )
[2] <Element> ::= ( <name> <attributes-list>? <child-of-element>* )
[3] <attributes-list> ::= ( @ <attribute>* )
[4] <attribute> ::= ( <name> "value"? )
[5] <child-of-element> ::= <Element> | "character data" | <PI>
[6] <PI> ::= ( *PI* pi-target "processing instruction content string" )

Рис. 1: Упрощенная грамматика SXML


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

Рисунок 2 иллюстрирует XML-элемент и его SXML-представление (удовлетворяющее продукции <Element> из рисунка 1).


<WEIGHT unit="pound">
  <NET
   certified="certified">67</NET>
  <GROSS>95</GROSS>
</WEIGHT>
(WEIGHT (@ (unit "pound"))
  (NET
   (@ (certified)) "67")
  (GROSS "95")
)

Рис. 2: XML-элемент (слева) и его представление в SXML (справа)


Значением атрибута обычно является строка; она может опускаться (в случае HTML) для булевского атрибута, например, атрибута "certified" на рис. 2.

Коллекция атрибутов считается полноправным информационным элементом, помеченным специальным именем @ . Символ "@" не может встретиться в корректном XML-имени; поэтому список атрибутов <attributes-list> не может быть перепутан со списком, отображающим элемент. XML-документ представляет атрибуты, команды по обработке и другие мета-данные отлично от разметки элемента. Напротив, SXML представляет содержимое элемента и мета-данные однородно -- как именованные списки. Язык описания схемы XML-документа RELAX NG [11] также нацелен на то, чтобы рассматривать атрибуты настолько похожим на элементы образом, насколько это возможно. Подобное однородное рассмотрение, утверждает Джеймс Кларк [12], -- это важный фактор для упрощения языка. SXML пользуется преимуществом того факта, что каждое имя языка XML является корректным идентификатором языка Схема, но не каждый идентификатор в Схеме является корректным именем в XML. Это наблюдение позволяет нам ввести служебные имена, такие как @, *PI*, *TOP*, не беспокоясь по поводу потенциального совпадения имен. Это наблюдение также хорошо определяет соотношение между XML и SXML. XML-документ, преобразованный в SXML, может быть снова реконструирован в XML-представление, эквивалентное исходному с точки зрения XML Infoset. Более того, благодаря абстрактности модели данных Infoset и возможности ее последующей конкретизации, SXML сам является примером XML Infoset.

XML Recommendation определяет, что команды по обработке (processing instructions, PI) отличаются от элементов и текстовых данных; команды по обработке должны передаваться приложению. SXML использует узлы специально выделенного типа *PI* для представления PI. Аналогичный подход используют XPath и DOM Level 2.

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


<?xml version='1.0'>
<di contract="728g">
  <wt refnum="345">
    <delivery>
       <date month="6" 
             day="01" 
             year"2001"/>
       <weight>783</weight>
    </delivery>
    <vehicle type="lorry" 
      number="A567TP99"/>
  </wt>
  <wt refnum="459">
     <vehicle type="car" 
              number="25676043"/>
  </wt>
</di>
(*TOP* (*PI* xml "version='1.0'") 
(di (@ (contract "728g"))
  (wt (@ (refnum "345")) 
    (delivery
      (date (@ (month "6") 
               (day "1") 
               (year "2001")))
      (weight "783"))

    (vehicle (@ (type "lorry") 
                (number "A567TP99"))))

  (wt (@ (refnum "459")) 
    (vehicle (@ (type "car")
                (number "25676043"))))
  )
)

Рис. 3: XML-документ (слева) и его представление в SXML (справа)


SXML можно рассматривать также как абстрактное дерево разбора XML-документа (abstract syntax tree). XML-документ или любая правильно сформированная (well-formed) его часть могут быть автоматически преобразованы в соответствующий SXML-вид с помощью чисто функционального, написанного на Схеме парсера SSAX [13].

Необходимо отметить, что SXML моделирует XML во всех деталях, включая комментарии, пространства имен и внешние сущности. Эти конструкции в данных материалах для простоты изложения не рассматриваются, и изложены в спецификации SXML [9].

2.3  Свойства SXML

Данный подраздел рассматривает некоторые свойства SXML [3], следующие из его грамматики и свойств S-выражений.

2.3.1  SXML-документ как дерево узлов

Так как SXML-документ представляет собой древовидную структуру данных, дополнительное введение понятия SXML-узла (node) для вершин этого дерева делает возможным более однородное описание SXML-документа.

SXML-узел может быть определен на основе рассмотренной выше грамматики (рис. 1) за счет добавления единственной новой продукции -- [N] на рис. 4. Альтернативно, SXML-узел можно определить через два взаимно-рекурсивных типа данных -- продукции [N1], [N2] и [N3] на рис. 4. Во втором случае Node создается присоединением имени к левому концу списка Nodelist; Nodelist, в свою очередь, является упорядоченным списком узлов (Node).


[N] <Node> ::= <Element> | <attributes-list> | <attribute> | "character data: text string" | <TOP> | <PI>
[N1] <Node> ::= ( <name1> . <Nodelist> ) | "text string"
[N2] <Nodelist> ::= ( <Node> <Node>* )
[N3] <name1> ::= <name> | @ | *TOP* | *PI*

Рис. 4: SXML-документ как дерево узлов


Такое рассмотрение SXML подчеркивает его древовидную структуру и однородное представление информационных элементов XML Infoset в виде S-выражений языка Схема.

2.3.2  Элементы и атрибуты в SXML

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

Особенно удобно на практике однородное представление в SXML элементов и атрибутов [14]. Различия между элементами и атрибутами в XML достаточно размыты, выбор атрибута или элемента для представления конкретной информации является часто вопросом стиля [15] и может быть пересмотрен в дальнейшем. В SXML такое изменение структуры данных выражается как добавление (или удаление) одного уровня вложенности (а именно, списка атрибутов) и требует минимальной модификации SXML-приложений. Узел атрибута отличается от элемента в SXML лишь тем, что он вложен в список атрибутов (который также является специальным XML-узлом) и не может содержать вложенных элементов.

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

(delivery
  ...
  (weight "789")))

изменится на следующее:

(delivery
  (@ (weight "789"))
  ...)

Такое представление элементов и атрибутов упрощает реструктуризацию SXML-данных и позволяет использовать для их обработки однотипные запросы.

2.3.3  SXML-данные как программа на Схеме

Синтаксис языков семейства Лисп, и Схемы в частности, основан на использовании S-выражений для представления как данных, так и кода программ. Это делает возможным и удобным рассмотрение программ на Схеме как слабоструктурированных данных [16] и наоборот.

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

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

Например, если определить para и bold как функции:

(define (para . x) (cons 'p x))
(define (bold . x) (cons 'b x))

то SXML-элемент

(para "plain" 
      (bold "highlighted") 
      "plain")

может рассматриваться как программа, а результатом ее выполнения будет SXML-элемент:

(p "plain" 
   (b "highlighted") 
   "plain")

Отметим, что результатом выполнения подобной программы не обязательно должен быть SXML-элемент. Так, программа может возвращать текстовое представление исходных данных в формате XML или HTML [17], или даже выполняться для достижения побочного эффекта, такого как сохранение SXML-данных в реляционной базе данных.

3  Пространства имен в XML и SXML

Хотя Рекомендация XML [5] была введена в употребление без идеи пространства имен, на пространствах имен основаны большинство технологий, имеющих отношение к XML, и Рекомендация о Пространствах Имен в XML [18] была опубликована Консорциумом Мировой Сети (World Wide Web Consortium) в январе 1999 года, вскоре после появления самой Рекомендации XML.

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

Пространства имен, поддерживаемые SXML, могут рассматриваться как надмножество пространств имен в XML. В данном разделе мы обсуждаем дизайн и реализацию пространств имен в XML и SXML и производим их сравнение. Обсуждение иллюстрируется Моделью Описания Ресурсов (Resource Description Framework) и Dublin Core, которые активно используются в приложениях электронных библиотек.

3.1  Пространства имен в XML

В модели данных XML подразумевается, что XML-документ содержит в себе дерево элементов. Каждый элемент имеет тип [18] (иногда называемый также именем тэга) и набор атрибутов; каждый атрибут состоит из имени и значения. Тип элемента в общем случае предназначен для того, чтобы отражать семантическое назначение элемента. Как обсуждается в [19], приложения обычно анализируют тип элемента и его атрибуты, чтобы определить, как обрабатывать этот элемент.

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

<book>
  <part>...</part>
  <part>...</part>
</book>
<car>
  <part>...</part>
</car>

Приложение не имеет возможности узнать, как обрабатывать элемент part, если ему не предоставить некоторую дополнительную информацию, внешнюю по отношению к XML-документу. В нашем простом примере можно различить элементы part, анализируя типы их родительских элементов (book vs. car); однако в общем случае такой подход неудобен.

Аналогичные коллизии имен могут возникнуть и с XML-атрибутами. Рассмотрим первого разработчика, который использует атрибут color, чтобы выразить тот факт, что внешнее представление элемента title на экране должно иметь красный цвет:

<title color="red">...</title>

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

<title color="red" color="gray16"/>...</title>

Мы не только не способны различить эти два атрибута. Элемент в последнем примере -- неправильный (not a well-formed) XML-элемент, поскольку Рекомендация XML не разрешает XML-элементу иметь несколько атрибутов с одинаковыми именами.

Рекомендация о Пространствах Имен в XML пытается улучшить эту ситуацию за счет расширения модели данных, которая позволила бы квалифицировать типы элементов и имена атрибутов с помощью Унифицированного Идентификатора Ресурса (Uniform Resource Identifier, URI). Таким образом, документ, описывающий части машин, может использовать тип part, квалифицированный одним Унифицированным Идентификатором Ресурса; а документ, описывающий части книг, может использовать тип part, квалифицированный другим Унифицированным Идентификатором Ресурса. Как отмечается в [19], роль Унифицированного Идентификатора Ресурса в имени -- просто позволить приложению распознать имя. Не дается никаких гарантий относительно реального существования какого-либо ресурса по данному URI. Рекомендация о Пространствах Имен в XML не требует, чтобы типы элементов и имена атрибутов были квалифицированными именами (еще называемые полными именами); они также могут оставаться неквалифицированными именами (которые также называют локальными именами).

Рекомендация о Пространствах Имен в XML квалифицирует имена с помощью Унифицированных Идентификаторов Ресурсов косвенным способом, который основан на идее префикса. Если тип элемента или имя атрибута содержит двоеточие, то часть имени, стоящая перед двоеточием, рассматривается как префикс, а часть имени после двоеточия -- как локальное имя. Префикс foo ссылается на Унифицированный Идентификатор Ресурса, определяемый значением атрибута xmlns:foo.

Например, типы всех XML-элементов, описывающих книги, можно квалифицировать каким-то общим Унифицированным Идентификатором Ресурса -- "http://www.books.com/xml". Тогда элемент, который описывает части книг (т.е. локальное имя которого -- part), будет представлен на XML как:

<books:part xmlns:books="http://www.books.com/xml">...</books:part>

Ситуация с именами атрибутов -- точно такая же, как и с типами элементов. Например:

<title xmlns:display="http://www.computer-displays.org"
       xmlns:printer="http://www.bwprinters.net"
       display:color="red"
       printer:color="gray16"/>...</title>

Все эти атрибуты xmlns достаточно громоздки, поэтому Рекомендация о Пространствах Имен в XML позволяет их наследовать [19]: если префикс foo используется в имени тэга, но элемент не содержит атрибута xmlns:foo, то будет использоваться значение атрибута xmlns:foo из родительского элемента; если родительский элемент также не содержит атрибута xmlns:foo, то будет использоваться значение атрибута xmlns:foo из его родительского элемента, и т.д. Например,

<books:book xmlns:books="http://www.books.com/xml">
  <books:part>...</books:part>
  <books:part>...</books:part>
</books:book>

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

Часто возникает ситуация, когда большинство элементов в документе имеют квалифицированные типы элементов с одним и тем же Унифицированным Идентификатором Ресурса. Рекомендация о Пространствах Имен для XML имеет специальный синтаксис, чтобы сделать этот случай еще более удобным для записи. Атрибут xmlns определяет Унифицированный Идентификатор Ресурса, который будет использоваться для квалифицирования всех типов элементов, не содержащих префикса. Атрибут xmlns наследуется точно так же, как и атрибуты с префиксами xmlns:. Таким образом, предыдущий пример можно переписать как:

<book xmlns="http://www.books.com/xml">
  <part>...</part>
  <part>...</part>
</book>

Необходимо отметить, что атрибут xmlns не влияет на имена атрибутов, не содержащих префиксов.

3.2  Пространства имен в SXML

Поскольку SXML уже был нами введен в разделе 2, в данном подразделе мы обсудим дизайн и реализацию пространств имен в SXML.

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

(http://www.books.com/xml:book
  (http://www.books.com/xml:part ...)
  (http://www.books.com/xml:part ...))

Самое правое двоеточие в SXML-имени отделяет локальное имя от Унифицированного Идентификатора Ресурса, определяющего пространство имен.

Хотя такие длинные имена SXML-элементов в написанном виде выглядят громоздкими, они эффективны как структуры данных с точки зрения занимаемой памяти, поскольку являются символами языка Схема. Неважно, насколько длинным будет имя символа, -- это длинное имя представлено только один раз, в таблице символов. Все дальнейшие вхождения символа -- это лишь ссылки на соответствующую ячейку в таблице символов [9].

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

В SXML мы можем использовать либо контейнеры, либо сами названия пространств имен.

Помимо непосредственного способа расширения имен Унифицированными Идентификаторами Ресурсов, SXML поддерживает концепцию идентификаторов пространств имен, которые определенным образом напоминают префиксы пространств имен в XML. Аналогично префиксу, идентификатор пространства имен соответствует Унифицированному Идентификатору Ресурса, определяющему пространство имен. Отличительной чертой идентификаторов пространства имен является то, что существует взаимно однозначное соответствие между ними и Унифицированными Идентификаторами Ресурсов, определяющими пространства имен. Это в общем случае не так для префиксов пространства имен в XML. Например, различные префиксы могут определять один и тот же Унифицированный Идентификатор Ресурса; префиксы могут переопределяться в дочерних элементах.

Идентификатор пространства имен, таким образом, служит в качестве сокращения для Унифицированного Идентификатора Ресурса в SXML-именах. Соответствие между идентификаторами пространства имен и Унифицированными Идентификаторами Ресурсов задается в служебной вершине *NAMESPACES*, которая располагается перед элементом документа. Пример законченного SXML-документа с пространствами имен показан на рис. 5.


(*TOP*
 (@@
  (*NAMESPACES*
    (rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
    (dc "http://purl.org/dc/elements/1.1/")))
 (*PI* xml "version=\"1.0\"")
 (rdf:RDF
   (rdf:Description
     (dc:creator "Karl Mustermann")
     (dc:title "Algebra")
     (dc:subject "mathematics")
     (dc:date "2000-01-23")
     (dc:language "EN")
     (dc:description "An introduction to algebra"))))

Рис. 5: Пример SXML-документа с пространствами имен


Рис. 6 иллюстрирует соответствие между префиксами в XML, квалифицированными явным образом именами в SXML, и идентификаторами пространства имен. Приведенный документ содержит некоторое описание ресурса, выраженное с помощью Модели Описания Ресурсов (Resource Description Framework), которая будет подробно рассмотрена в пункте 3.3.2. Модель Описания Ресурсов имеет собственное пространство имен, и для него обычно используется префикс rdf:. Предположим, что еще одно пространство имен, имеющее Унифицированный Идентификатор Ресурса "http://www.resources-of-different-family.com", встречается в этом документе; "rdf" является наглядным сокращением для этого Унифицированного Идентификатора Ресурса, поэтому для него также будет использоваться префикс rdf:. В XML подобная ситуация вызывает определенную путаницу, поскольку требуется переопределение значений префикса. В SXML с квалифицированными явным образом именами, документ выглядит понятно, хотя и громоздко из-за длинных имен. SXML, использующий идентификаторы пространства имен, выглядит наиболее естественно, поскольку идентификаторы пространства имен ликвидируют переопределения и позволяют сохранить имена краткими.


<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
    <rdf:editor xmlns:rdf="http://www.resources-of-different-family.com">
      <rdf:Description xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
        <rdf:fullName xmlns:rdf="http://www.resources-of-different-family.com"
        >Dave Beckett</rdf:fullName>
      </rdf:Description>
    </rdf:editor>
  </rdf:Description>
</rdf:RDF>

(*TOP*
 (*PI* xml "version=\"1.0\"")
 (http://www.w3.org/1999/02/22-rdf-syntax-ns#:RDF
   (http://www.w3.org/1999/02/22-rdf-syntax-ns#:Description
     (@
      (http://www.w3.org/1999/02/22-rdf-syntax-ns#:about
        "http://www.w3.org/TR/rdf-syntax-grammar"))
     (http://www.resources-of-different-family.com:editor
       (http://www.w3.org/1999/02/22-rdf-syntax-ns#:Description
         (http://www.resources-of-different-family.com:fullName
           "Dave Beckett"))))))

(*TOP*
 (@@
  (*NAMESPACES*
    (rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
    (family "http://www.resources-of-different-family.com")))
 (*PI* xml "version=\"1.0\"")
 (rdf:RDF
   (rdf:Description
     (@ (rdf:about "http://www.w3.org/TR/rdf-syntax-grammar"))
     (family:editor
       (rdf:Description
         (family:fullName "Dave Beckett"))))))

Рис. 6: XML документ, содержащий переопределения префиксов (наверху), и его представление в SXML с использованием квалифицированных явным образом имен (в центре), и с использованием идентификаторов пространств имен (внизу).


В общем случае, один префикс пространства имен в пределах XML-документа может быть ассоциирован с несколькими разными Унифицированными Идентификаторами Ресурсов; однако XML-документы без подобных множественных определений (т.е. такие, где соответствие между префиксами и Унифицированными Идентификаторами Ресурсов взаимно однозначно), составляют существенное подмножество "практических" XML-документов. Поскольку правила хорошего стиля предлагают производить все объявления префиксов в элементе документа, концепция префиксов в XML фактически очень близка к концепции идентификаторов пространства имен в SXML.

3.3  Применение пространств имен в контексте электронных библиотек

В данном подразделе рассматривается Dublin Core, набор мета-элементов, предназначение которых -- облегчать поиск электронных ресурсов, включая электронные библиотеки (ЭБ). Описывается представление Dublin Core на XML/RDF, что является иллюстративным примером практического применения пространств имен XML в контексте основанных на XML электронных библиотек.

3.3.1  Dublin Core

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

Библиотекари, исследователи в области электронных библиотек и специалисты по разметке текстов собрались на пригласительном семинаре, проведенном в марте 1995 года, чтобы обратиться к проблеме нахождения ресурсов в сети. Это деятельность переросла в серию родственных семинаров и вспомогательных мероприятий, которые все вместе стали известны как Серия Семинаров по Метаданным Dublin Core.

Одним из основных результатов этих усилий стал набор элементов, которые коллективным мнением участников данных семинаров выбраны как основные элементы в области междисциплинарного поиска ресурсов. Термин "Dublin Core" применяется к этому основному ядру описательных элементов [20].

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

  1. элементы, относящиеся, главным образом, к Содержимому ресурса,
  2. элементы, относящиеся, главным образом, к ресурсу с точки зрения Интеллектуальной Собственности, и
  3. элементы, относящиеся, главным образом, к Представлению ресурса.

Рис. 7 демонстрирует эти 3 группы из 15 элементов Dublin Core.


Содержимое Интеллектуальная Собственность     Представление
Заголовок (Title) Создатель (Creator) Дата (Date)
Предмет (Subject) Издатель (Publisher) Формат (Format)
Описание (Description)     Помощник (Contributor) Идентификатор (Identifier)
Тип (Type) Права (Rights) Язык (Language)
Источник (Source)
Отношение (Relation)
Освещение (Coverage)

Рис. 7: Мета-элементы Dublin Core


Любой элемент необязателен, или может встречаться несколько раз. Мета-элементы могут появляться в любом порядке. Упорядоченность нескольких вхождений одного и того же элемента (например, Создатель) может иметь значение, предполагаемое автором мета-описания; однако сохранение порядка не гарантируется в каждой пользовательской среде. В частности, RDF/XML поддерживает упорядочивание, в то время как HTML -- нет.

Мы дадим короткое описание нескольких элементов из Dublin Core, которые имеют особый интерес в контексте электронных библиотек:

Заголовок (Title)
Имя, данное ресурсу.
Автор или Создатель (Creator)
Человек или организация, которые в первую очередь ответственны за интеллектуальное содержимое ресурса, например, авторы в случае печатных документов.
Предмет и Ключевые Слова (Subject)
Тема ресурса. Обычно, тема выражается как ключевые слова или фразы, описывающие предмет или содержимое ресурса.
Описание (Description)
Текстовое описание содержимого ресурса, например, аннотация в случае объектов, представляющих собой документы.
Тип Ресурса (Type)
Категория ресурса, такие как домашняя страница, роман, поэма, деловая бумага, технический отчет, эссе, словарь.
Идентификатор Ресурса (Identifier)
Строка или число, уникальным образом идентифицирующие ресурс. Примеры для сетевых ресурсов включают Унифицированный Идентификатор Ресурса (Uniform Resource Identifier, URI) и Унифицированное Имя Ресурса (Uniform Resource Name, URN). Другие уникальные в глобальном масштабе идентификаторы, такие как Международный Стандартный Номер Книги (International Standard Book Number, ISBN) или другие формальные имена -- также являются кандидатами для этого элемента.

Мета-элементы, как правило, имеют некоторое отношение к ресурсу, который они описывают, и, если формат ресурса позволяет, они могут быть включены внутрь тела ресурса. Два таких формата -- это Гипертекстовый Язык Разметки (Hypertext Markup Language, HTML) [21] и Расширяемый Язык Разметки (Extensible Markup Language, XML). В настоящее время активно используется HTML, но, с появлением стандарта XML, XML совместно с Моделью Описания Ресурсов (Resource Description Framework, RDF) обещают значительно более выразительные средства для представления мета-данных.

В пункте 3.3.2 мы рассмотрим представление Dublin Core на RDF/XML.

3.3.2  Представление Dublin Core в Модели Описания Ресурсов (RDF)

Модель Описания Ресурсов (Resource Description Framework, RDF), разработанная под эгидой Консорциума Всемирной сети (World Wide Web Consortium, W3C) -- это инфраструктура, позволяющая осуществлять представление, передачу и повторное использование структурированных метаданных [22]. Модель Описания Ресурсов использует XML в качестве общего синтаксиса для передачи и обработки метаданных.

RDF -- результат совместных потребностей нескольких сообществ в выразительной и гибкой архитектуре для поддержки метаданных в сети. RDF -- это коллективная разработка, в которую вкладывают свои интеллектуальные ресурсы несколько компаний, являющихся членами Консорциума Всемирной сети. RDF исходит из дизайна XML, а также из предложений, поданных компаниями Microsoft и Netscape. Усилия других групп в области метаданных, включая Dublin Core и Warwick Framework, также повлияли на дизайн RDF.

RDF предоставляет модель для описания ресурсов. RDF определяет ресурс как любой объект, который может быть уникальным образом идентифицирован с помощью Унифицированного Идентификатора Ресурса (Uniform Resource Identifier, URI). Ресурсы имеют свойства (атрибуты или характеристики). Набор свойств, которые относятся к одному и тому же ресурсу, называется описанием. В основе RDF находится независимая от синтаксиса модель для представления ресурсов и соответствующих им описаний.

Структура, лежащая в основе любого выражения в RDF, может рассматриваться как ориентированный помеченный граф, который состоит из вершин и помеченных дуг [23]. Граф RDF -- это набор троек: Вершина-предмет, Дуга-Свойство и Вершина-объект. Тройка показана на рис. 8.



Рис. 8: Тройка в RDF


Каждая дуга обозначает утверждение о некотором отношении между предметами, обозначаемыми вершинами, которые соединяет эта дуга. Данное утверждение имеет три части:

  1. свойство, описывающее некоторое отношение (которое также называется предикатом,
  2. значение, являющееся предметом утверждения, и
  3. значение, являющееся объектом утверждения.

Направление дуги существенно: она всегда указывает в сторону объекта утверждения.

Например, модель данных, соответствующая утверждению "автор Документа 1 -- Джон Смит", имеет объект Документ 1, дугу с пометкой автор и соответствующий предмет Джон Смит. Модель данных, отвечающая данному утверждению, графически выражается на рис. 9.



Рис. 9: Тройка, выражающая соотношение между документом и его автором


Общий смысл графа RDF -- это соединение (т.е. логическое "И") всех утверждений, которые он содержит.

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

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

Чтобы создать законченный RDF/XML-документ, сериализованный в вид XML граф должен быть помещен внутрь элемента rdf:RDF, который становится элементом верхнего уровня (элементом документа, document element). Префикс rdf: связан с пространством имен RDF -- "http://www.w3.org/1999/02/22-rdf-syntax-ns#" -- чтобы приложения могли распознать данный XML-документ как документ RDF/XML.

RDF дает возможность разным сообществам определять собственную семантику описаний. Важно, однако, избегать семантической двусмысленности описаний между различными сообществами. Свойство типа "автор", например, может иметь более широкое или более узкое значение в зависимости от нужд конкретного сообщества. Будет проблематичным, если множество сообществ будут использовать свойство одного типа, чтобы подразумевать под ним совершенно разные вещи. Чтобы предотвратить это, RDF уникальным образом идентифицирует свойства с использованием механизма пространства имен в XML. Пространства имен в XML предоставляют возможность однозначно идентифицировать семантику и соглашения, управляющие использованием конкретного свойства, за счет уникальной идентификации руководящей организации. В качестве примера можно привести свойство типа "автор", определенное Инициативой Dublin Core как "лицо или организация, ответственные за создание интеллектуального содержимого ресурса" и специфицированное элементом CREATOR Dublin Core. Пространство имен в XML используется для однозначной идентификации схемы для словаря Dublin Core, путем указания на ресурс Dublin Core, который определяет соответствующую семантику.

Пятнадцать базовых элементов из Набора Элементов Dublin Core могут рассматриваться как составляющие единое пространство имен [25], на которое можно ссылаться во Всемирной сети как "http://purl.org/dc/elements/1.1/".

Каждый элемент Dublin Core представляется в RDF как XML-элемент:

  • идентификатор пространства имен которого -- "http://purl.org/dc/elements/1.1/", и
  • локальное имя которого совпадает с именем элемента Dublin Core.

XML-элемент rdf:RDF является элементом верхнего уровня (элементом документа) в документе RDF/XML; и каждый описываемый ресурс включается в элемент rdf:Description. Рис. 10 дает пример описания Dublin Core, выраженного на RDF/XML.


<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/">  
  <rdf:Description>
    <dc:creator>Karl Mustermann</dc:creator>
    <dc:title>Algebra</dc:title>
    <dc:subject>mathematics</dc:subject>
    <dc:date>2000-01-23</dc:date>
    <dc:language>EN</dc:language>
    <dc:description>An introduction to algebra</dc:description>
  </rdf:Description>
</rdf:RDF>

Рис. 10: Описание Dublin Core, выраженная в RDF/XML


4  Язык XML Path (XPath) и его функциональная реализация SXPath

Язык XML Path (XPath) [8] -- это язык для адресации частей XML-документа [5]. XPath является ключевым языком для множества XML-технологий и используется многими важными XML-языками; в частности, XSLT, XPointer и XQuery.

В подразделе 3.3 мы обсуждали, как ресурсы электронных библиотек могут быть описаны с помощью Dublin Core и представлены в Модели Описания Ресурсов (Resource Description Framework, RDF) как XML-документ. Для удобства читателя мы еще раз повторим вид подобного описания на рис. 11, и будем далее ссылаться на него в этом разделе. Чтобы использовать такие описания ресурсов, приложению необходим инструмент для извлечения требуемой информации из XML-документа. Например, чтобы найти нужный ресурс в электронной библиотеке, приложение, вероятно, захочет адресоваться к некоторым полям в описании ресурса -- для их анализа на предмет удовлетворения условиям поиска. Поскольку поля в описании на RDF/XML являются частями XML-документа, XPath, обсуждаемый в данном разделе, является основным инструментом для подобной адресации.


<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/">  
  <rdf:Description>
    <dc:creator>Karl Mustermann</dc:creator>
    <dc:title>Algebra</dc:title>
    <dc:subject>mathematics</dc:subject>
    <dc:date>2000-01-23</dc:date>
    <dc:language>EN</dc:language>
    <dc:description>An introduction to algebra</dc:description>
  </rdf:Description>
</rdf:RDF>

Рис. 11: XML-документ (иллюстрирующий описание книги с помощью Dublin Core, выраженное в Модели Описания Ресурсов)


4.1  Обзор XPath

Назначение XPath -- это адресация частей XML-документа. XPath трактует документ как дерево узлов, -- поскольку XML-документ является, в сущности, древовидной структурой. Адресация частей документа производится с помощью так называемого пути доступа (location path) [26], имеющего текстовый синтаксис. Путь доступа обычно применяется к корню XML-документа, и результат вычисления пути доступа для этого документа -- это набор узлов (node-set) [26], состоящий из (возможно, нескольких) узлов, выбранных с помощью данного пути доступа. Выбранные узлы соответствуют XML-элементам, атрибутам, текстовым данным и другим частям исходного XML-документа.

Пример пути доступа языка XML Path приводится на рис. 12. Путь доступа состоит из последовательности одного или более шагов доступа (location steps), разделенных символом /. Так, путь доступа на рис. 12 состоит из 4 шагов доступа.


rdf:RDF/rdf:Description/dc:title/text()

Рис. 12: Пример пути доступа


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

Шаг доступа состоит из трех частей [8]:

  • Оси (axis), определяющей соотношение в дереве между узлами, в контексте которых вычисляется шаг доступа, и узлами, которые выбирает шаг доступа. Ось можно считать "направлением движения" по дереву, представляющему XML-документ. Спецификация XPath определяет 13 различных осей. Они включают в себя оси для спуска к листьям дерева, для подъема в сторону корня, для выбора соседних узлов и т.п. Синтаксически имя оси отделяется от остальной части шага адресации с помощью "::" (двойного двоеточия).
  • Теста узла (node test), определяющего тип и, возможно, имя узлов, выбираемых шагом доступа. В то время как ось определяет "направление движения", тест узла определяет желаемые узлы, которые должны быть выбраны.
  • Нуля или более предикатов (predicates). Каждый предикат синтаксически записывается в квадратных скобках и используется для дальнейшего просеивания набора узлов, выбираемых шагом доступа.

Для краткости изложения мы не будем рассматривать предикаты XPath в данных материалах; читатель может ознакомиться с этим вопросом в [27].

Среди осей XPath наиболее важной является ось child. Эта ось включает в себя дочерние узлы контекстного узла. Для узла, представляющего собой XML-элемент, ось child выбирает его дочерние XML-элементы и дочерние текстовые узлы. Для корня документа, ось child выбирает элемент документа (document element). Данная ось используется в XPath по умолчанию, т.е. слово child:: можно опускать при написании шага адресации. В приведенном выше рис. 12, каждый шаг доступа использует ось child.

Из существующих в XPath тестов узлов мы рассмотрим два.

Тест узлов text() допускает только текстовые узлы. Другими словами, если мы будем использовать терминологию, принятую в Спецификации XPath [8], тест узлов text() есть истина для каждого текстового узла. В примере на рис. 12, последний (самый правый) шаг доступа использует этот тест узлов.

Тест узлов, представляемый (квалифицированным) XML-имемем, есть истина только для узла с тем же именем. Для узла, который представляет XML-элемент, именем узла является имя этого XML-элемента. В примере на рис. 12 первые три шага доступа используют тесты узлов, которые являются квалифицированными XML-именами (соответственно, rdf:RDF, rdf:Description и dc:title). Механизм разрешения префиксов пространств имен в XPath обсуждается более подробно в пункте 4.1.1.

Будучи примененным к корню XML-документа, показанного на рис. 11, путь доступа, рассмотренный на рис. 12, будет вычисляться следующим образом:

  1. Первый шаг доступа (вычисляемый относительно корня документа) выбирает множество узлов, состоящее лишь из элемента документа rdf:RDF (он удовлетворяет тесту узла);
  2. Второй шаг доступа выбирает все дочерние для элемента документа узлы с именем rdf:Description (в рассматриваемом документе есть ровно один такой узел);
  3. Аналогично, третий шаг доступа выбирает все элементы dc:title, являющиеся дочерними для выбранного на втором шаге элемента rdf:Description (в рассматриваемом документе такой элемент dc:title ровно один);
  4. Наконец, четвертый шаг доступа выбирает дочерние текстовые узлы для ранее выбранного элемента dc:title. Это вычисляется в набор узлов, состоящий из единственного текстового узла "Algebra", и это становится результатом вычисления всего пути доступа для данного документа.

Таким образом, путь доступа на рис. 12 адресуется к названию книги, описанной в XML-документе на рис. 11.

4.1.1  XPath и пространства имен

Элементы и атрибуты в XML-документе в общем случае имеют имена, квалифицированные [18] с помощью Унифицированного Идентификатора Ресурса (Uniform Resource Identifier, URI). Как обсуждалось в подразделе 3.1, роль Унифицированного Идентификатора Ресурса в имени -- просто позволить приложениям распознать имя. Рекомендация о Пространствах Имен в XML квалифицирует имена с помощью Унифицированных Идентификаторов Ресурсов косвенным способом, который основан на идее префикса. Если тип элемента или имя атрибута содержит двоеточие, то часть имени, стоящая перед двоеточием, рассматривается как префикс, а часть имени после двоеточия -- как локальное имя. Префикс foo ссылается на Унифицированный Идентификатор Ресурса, определяемый значением атрибута xmlns:foo [19]. Таким образом, имя вершины моделируется как пара, состоящая из локальной части и (возможно, отсутствующего) Унифицированного Идентификатора Ресурса пространства имен; все вместе называется расширенным именем (expanded-name).

Чтобы выбрать элементы и атрибуты, имеющие квалифицированные имена, XPath использует тест узлов, который сам является квалифицированным именем, т.е. он синтаксически состоит из локального имени и префикса, разделенных двоеточием. Квалифицированное имя в тесте узла преобразуется в расширенное имя с помощью набора объявлений пространств имен (namespace declarations) из контекста вычисляемого XPath-выражения. Набор объявлений пространств имен представляет собой отображение префиксов на Унифицированные Идентификаторы Ресурсов пространств имен. Тест узла, являющийся квалифицированным именем, есть истина, только если вершина имеет расширенное имя, совпадающее с расширенным именем для данного квалифицированного имени; т.е. у них совпадают Унифицированные Идентификаторы Ресурсов пространств имен и локальные имена.

Процессору XPath набор объявлений пространств имен предоставляется от пользователя XPath, в частности, от XSLT или XPointer. Рекомендации XSLT и XPointer специфицируют, как объявления пространств имен определяются для XPath-выражений, используемых в XSLT и XPointer соответственно.

Необходимо отметить, что набор объявлений пространств имен в XPath и объявления пространств имен в документе полностью независимы. В XML-документе, префикс foo ссылается на Унифицированный Идентификатор Ресурса, заданный в ближайшем атрибуте xmlns:foo; и имя префикса выбирается дизайнером документа. В пути доступа языка XML Path, префикс ссылается на набор объявлений пространств имен (namespace declarations); и имя префикса выбирается разработчиком приложения. Эти два вида префиксов никак не соотносятся друг с другом. Вместо этого, соответствующие им Унифицированные Идентификаторы Ресурсов пространств имен сравниваются при вычислении теста узлов.

Чтобы сделать наш пример пути доступа на рис. 12

корректным, нам теперь следует упомянуть набор объявлений пространств имен: префикс rdf: ассоциируется с пространством имен Модели Описания Ресурсов "http://www.w3.org/1999/02/22-rdf-syntax-ns#", а префикс dc: ассоциируется с пространством имен Dublin Core "http://purl.org/dc/elements/1.1/".

4.2  SXPath: реализация языка XML Path на Схеме

В данном подразделе мы рассмотрим SXPath [17] -- реализацию XPath на языке функционального программирования Схема (Scheme) [4].

Прежде всего, мы хотели бы заметить, что текстовое представление XML с парными угловыми скобками является лишь внешним представлением XML-документа [9]. Приложениям (и, в частности, процессорам XPath) приходится работать с его внутренним представлением, которое позволяло бы приложению находить конкретные данные или трансформировать их.

Например, реализации XPath могут использовать Объектную Модель Документа (Document Object Model, DOM) как интерфейс прикладного программирования для управления XML-данными. Как обсуждалось в разделе 1, большое различие между внешней текстовой нотацией XML и этой внутренней объектной моделью приводит к неприятной проблеме несоответствия импеданса [3].

Реализация XPath на Схеме позволяет нам использовать очень естественное и удобное внутреннее представление для XML-данных -- SXML [9]. SXML -- это представление для XML-документа в форме S-выражения. Как мы обсуждали в разделе 2, текстовые нотации XML и SXML довольно похожи: грубо говоря, SXML лишь использует круглые скобки вместо каждой пары угловых скобок. Это делает нотацию SXML простой для изучения, краткой и простой для восприятия, и простой для редактирования, даже вручную. SXML, таким образом, может рассматриваться как одновременно внешнее представление документа и его внутреннее представление. Для иллюстрации данной идеи, рис. 13 показывает SXML-аналог для XML-документа из рис. 11.


(*TOP*
 (@@
  (*NAMESPACES*
    (rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
    (dc "http://purl.org/dc/elements/1.1/")))
 (*PI* xml "version=\"1.0\"")
 (rdf:RDF
   (rdf:Description
     (dc:creator "Karl Mustermann")
     (dc:title "Algebra")
     (dc:subject "mathematics")
     (dc:date "2000-01-23")
     (dc:language "EN")
     (dc:description "An introduction to algebra"))))

Рис. 13: SXML-документ, соответствующий XML-документу из рис. 11


XML-документ может быть автоматически преобразован в соответствующий SXML-вид с помощью чисто функционального, написанного на Схеме парсера SSAX [13].

SXPath полностью соответствует Спецификации XPath Консорциума Всемирной Сети (World Wide Web Consortium). Рис. 14 иллюстрирует, как путь доступа, рассмотренный нами на рис. 12, может быть вычислен с помощью SXPath для показанного выше SXML-документа из рис. 13. Здесь мы предполагаем, что этот документ связан (bound) с идентификатором Схемы doc.


((sxpath "rdf:RDF/rdf:Description/dc:title/text()")
  doc)

Рис. 14: Вычисление пути доступа из рис. 12 с помощью SXPath (здесь мы предполагаем, что идентификатор doc связан с SXML-документом из рис. 13)


SXPath естественным образом моделирует набор узлов, выбираемых путем адресации, в виде списка Схемы, членами которого являются SXML-узлы. Таким образом, пример на рис. 14 возвращает список, состоящий из единственного текстового узла "Algebra".

SXPath разделяет непосредственно разбор пути доступа и его вычисление. Обработка XML с помощью SXPath состоит из двух последовательных фаз:

  1. Производится разбор пути доступа. Точнее, SXPath способен разбирать пути доступа с помощью "функциональных" шагов доступа, в дополнении к стандартному XPath. Результатом подобного разбора является функция, которая соответствует данному пути доступа. На рис. 14 эта фаза соответствует внутреннему выражению на Схеме:
    (sxpath "rdf:RDF/rdf:Description/dc:title/text()")
  2. Сконструированная функция применяется к SXML-документу. Получив документ в качестве аргумента, функция возвращает набор узлов, как результат вычисления пути доступа для данного документа. На рис. 14 эта фаза соответствует внешнему выражению на Схеме:
    ((...) doc)

Данный подход имеет следующие преимущества:

  • Функция, сконструированная с помощью SXPath, может неоднократно применяться к разным XML-документам. Скажем, мы можем привязать (bind) сконструированную функцию к идентификатору Схемы для последующих обращений:
    (define f (sxpath "rdf:RDF/rdf:Description/dc:title/text()"))

    -- и затем использовать эту функцию несколько раз:

    (f sxml-doc1)
    (f sxml-doc2)

    Например, это может быть полезно, когда мы вычисляем один и тот же путь доступа над несколькими документами или производим сравнение по образцу в XSLT [28]. Обратите внимание, что разбор пути доступа производится лишь один раз.

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

4.2.1  SXPath и пространства имен

Как обсуждалось в подразделе 3.2, SXML применяет концепцию идентификаторов пространств имен, которая определенным образом напоминает префиксы пространств имен в XML. Аналогично префиксу, идентификатор пространства имен соответствует Унифицированному Идентификатору Ресурса, определяющему пространство имен. Отличительной чертой идентификаторов пространства имен является то, что существует взаимно однозначное соответствие между ними и Унифицированными Идентификаторами Ресурсов, определяющими пространства имен. Это в общем случае не так для префиксов пространства имен в XML.

Идентификатор пространства имен, таким образом, служит в качестве сокращения для Унифицированного Идентификатора Ресурса в SXML-именах. Необходимо отметить, что идентификаторы пространства имен выбираются разработчиком приложения, потому что они вводятся во время преобразования XML-документа в SXML. Рис. 15 иллюстрирует эту идею с помощью вызова функции -- парсера SSAX [13]. Второй аргумент этого вызова определяет желаемые сокращения для некоторых конкретных Унифицированных Идентификаторов Ресурсов, определяющих пространства имен. При разборе XML-документа, SSAX автоматически разрешает XML-префиксы соответствующими Унифицированными Идентификаторами Ресурсов, а затем заменяет некоторые из них идентификаторами пространств имен, в соответствии с заданными сокращениями.


(ssax:xml->sxml
   (open-input-file "example.xml")
   '((rdf . "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
     (dc . "http://purl.org/dc/elements/1.1/")))

Рис. 15: Преобразование XML-документа в SXML с помощью парсера SSAX. Предполагая, что "example.xml" содержит документ из рис. 11, SSAX создаст SXML-документ, ранее показанный на рис. 13.


Поскольку и имена префиксов в пути доступа языка XML Path, и идентификаторы пространств имен в SXML-документе выбираются разработчиком приложения, SXPath по умолчанию предполагает, что префикс в пути доступа символизирует идентификатор пространства имен. Подобное поведение SXPath логично, поскольку идентификатор пространства имен является сокращением для Унифицированного Идентификатора Ресурса в SXML-именах. Формально, если набор объявлений пространств имен не предоставлен функции sxpath, каждый префикс, появляющийся в пути доступа, рассматривается как идентификатор пространства имен с тем же именем, т.е. никакого отображения префиксов не производится.

SXPath способен принимать набор объявлений пространств имен как необязательный второй аргумент. Использование этого аргумента иллюстрируется рисунком 16. Набор объявлений пространств имен, являясь списком пар (prefix . namespace-URI), определяет отображение с префиксов, встречающихся в пути доступа, на Унифицированные Идентификаторы Ресурсов, определяющие пространства имен. Данное отображение необходимо для вычисления пути доступа для SXML-документа с квалифицированными явным образом именами (см. подраздел 3.2), такого, как показан на рис. 17.


((sxpath "rdf:RDF/rdf:Description/dc:title/text()"
         '((rdf . "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
           (dc . "http://purl.org/dc/elements/1.1/")))
  doc2)

Рис. 16: Вычисление пути доступа из рис. 12 с помощью SXPath для SXML-документа с квалифицированными явным образом именами (здесь мы предполагаем, что идентификатор doc2 связан с SXML-документом из рис. 17)



(*TOP*
 (*PI* xml "version=\"1.0\"")
 (http://www.w3.org/1999/02/22-rdf-syntax-ns#:RDF
   (http://www.w3.org/1999/02/22-rdf-syntax-ns#:Description
     (http://purl.org/dc/elements/1.1/:creator "Karl Mustermann")
     (http://purl.org/dc/elements/1.1/:title "Algebra")
     (http://purl.org/dc/elements/1.1/:subject "mathematics")
     (http://purl.org/dc/elements/1.1/:date "2000-01-23")
     (http://purl.org/dc/elements/1.1/:language "EN")
     (http://purl.org/dc/elements/1.1/:description
       "An introduction to algebra"))))

Рис. 17: SXML-документ с квалифицированными явным образом именами, соответствующий XML-документу из рис. 11


4.3  Низкоуровневые функции SXPath

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

Как упоминалось в подразделе 4.2, SXPath моделирует наборы узлов XPath как списки Схемы, членами которых являются SXML-узлы. Хотя сами узлы в SXML часто также представляют собой списки, мы всегда можем отличить набор узлов от отдельного узла: если узел представляет собой список, то его первым членом всегда будет символ Схемы (имя узла). Напротив, непустой набор узлов очевидно имеет своим первым членом SXML-узел, который никогда не может быть символом Схемы.

Предикат nodeset?, предоставляемый библиотекой SXPath, реализует в точности эту логику: он возвращает истину либо для пустого списка (пустого набора узлов), либо для списка, первым членом которого не является символ Схемы. Реализация предиката nodeset? показана на рис. 18; car -- это базовая функция Схемы, возвращающая первый член списка-аргумента.


(define (nodeset? x)
  (or (null? x)   ; пустой набор узлов
      (and (list? x) (not (symbol? (car x))))))

Рис. 18: Предикат для различения набора узлов и отдельного узла


Как обсуждалось в подразделе 4.1, тест узла в XPath служит для того, чтобы специфицировать условие на узлы, выбираемые с помощью шага доступа. Поскольку Рекомендация XPath определяет тест узла в терминах "быть истинным для некоторого вида узлов", естественно реализовывать тест узла как предикат, который принимает SXML-узел и возвращает булевское значение в зависимости от того, удовлетворяет ли узел тесту узла.


(define (text? node)
  (string? node))

(define (ntype?? name)
  (lambda (node)
    (and (list? node)   ; текстовый узел не имеет имени
         (eq? name (car node)))))

Рис. 19: Реализация некоторых тестов узлов XPath


Рис. 19 дает упрощенную реализацию двух тестов узлов XPath, которые рассматриваются нами в данных материалах:

  • Функция text? реализует тест узла text(), который допускает только текстовые узлы. В SXML текстовый узел представляется как строка (string) Схемы, поэтому стандартный предикат string? выполняет эту задачу.
  • Функция ntype?? реализует тест узла, который есть истина для узла с конкретным именем. Эта функция сначала параметризуется именем (name), и затем возвращает предикат, применимый к узлам:
    (lambda (node)
      (and (list? node)   ; текстовый узел не имеет имени
           (eq? name (car node))))

    Реализация этого предиката очевидна: узел должен быть списком (поскольку текстовый узел вообще не имеет имени) и первый член этого списка (получаемый с помощью car) должен совпадать с параметром name.

Реализация оси child, показанная на рис. 20

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


(define (select-kids node-test)
  (lambda (node)
    (if (text? node)
        '()     ; нет дочерних узлов
        (filter node-test (cdr node)))))

Рис. 20: Упрощенная реализация оси child


Поскольку ось и тест узла действуют совместно, SXPath проектирует оси как параметризуемые с помощью предикатов, реализующих тесты узлов. Получив предикат node-test, функция select-kids создает функцию, принимающую на вход SXML-узел node и возвращающую его потомков, удовлетворяющих тесту узла:

(lambda (node)
  (if (text? node)
      '()     ; нет дочерних узлов
      (filter node-test (cdr node)))))

Текстовый узел, очевидно, не имеет дочерних узлов, поэтому в этом случае возвращается пустой набор узлов. Иначе узел node является списком; и его дочерние узлы, выбираемые базовой функцией Схемы cdr, фильтруются в соответствии с предикатом node-test. Функция filter оставляет только те дочерние узлы, для которых предикат node-test есть истина.

Поскольку SXML представляет элементы и атрибуты однородным образом (см. подраздел 2.2), специальная реализация для оси attribute не требуется: в SXPath она является лишь частным случаем оси child.

Библиотека SXPath включает в себя несколько функций, играющих роль комбинаторов. В частности, комбинатор node-join соединяет (joins) несколько функций, каждая из которых реализует отдельный шаг доступа, в законченный путь доступа. Реализация node-join является чисто технической и здесь не приводится. Вместо этого, на рис. 21 мы проиллюстрируем одну конкретную комбинацию уже рассмотренных низкоуровневых примитивов SXPath. Легко видеть, что эта комбинация включает в себя четыре шага доступа, и реализует путь доступа из рис. 12. Апостроф используется для включения литеральных констант в код на Схеме.


(node-join
 (select-kids (ntype?? 'rdf:RDF))
 (select-kids (ntype?? 'rdf:Description))
 (select-kids (ntype?? 'dc:title))
 (select-kids text?))

Рис. 21: Комбинация низкоуровневых примитивов SXPath, которая образует функцию для вычисления пути доступа из рис. 12.


4.4  Высокоуровневые функции SXPath

Главная функция, предоставляемая библиотекой SXPath -- это sxpath. Мы упомянули эту функцию в подразделе 4.2, а здесь будем обсуждать ее более подробно.

Функция sxpath, получив на входе путь доступа, разбирает его в соответствии с грамматикой XPath и переводит его в комбинацию низкоуровневых примитивов SXPath, часть из которых была рассмотрены в подразделе 4.3. Например, если мы вернемся к рис. 14, его внутреннее выражение

(sxpath "rdf:RDF/rdf:Description/dc:title/text()")

сконструирует функцию, очень похожую на ту, что была показана на рис. 21. Низкоуровневые функции SXPath, таким образом, составляют виртуальную машину, в которую компилируются выражения более высокого уровня [29].

В дополнение к "текстовому", соответствующему Спецификации XPath синтаксису для представления пути доступа, библиотека SXPath также вводит свое собственное "родное" представление для пути доступа -- в форме списка. В этом представлении шаги доступа записываются как члены списка. Идея иллюстрируется рисунком 22, а его внутреннее выражение

(sxpath '(rdf:RDF rdf:Description dc:title *text*))

также сконструирует функцию, очень похожую на ту, что была показана на рис. 21.


((sxpath '(rdf:RDF rdf:Description dc:title *text*))
 doc)

Рис. 22: Вычисление "родного" SXPath-аналога для пути доступа из рис. 12 (здесь мы предполагаем, что идентификатор doc связан с SXML-документом из рис. 13)


С помощью данного "родного" представления для пути доступа, SXPath обеспечивает естественную возможность для функции Схемы -- служить в качестве одного из шагов в пути доступа, -- поскольку в SXPath функция Схемы является низкоуровневым представлением для шага доступа. Чтобы проиллюстрировать это утверждение, мы перепишем наш пример из рис. 22, представив третий шаг доступа в его явной форме, как низкоуровневый примитив SXPath (рис. 23). Следует заметить, что примеры на рисунках 14, 22 и 23 имеют одинаковую семантику. Хотя может показаться, что пример на рис. 23 лишь добавляет излишнюю сложность, он позволяет проиллюстрировать очень важное свойство SXPath. А именно, возможность использовать произвольную функцию Схемы как шаг доступа в пути доступа обеспечивает SXPath практически неограниченными возможностями. В частности, это свойство делает SXPath языком запросов, о чем будет говориться в следующем подразделе.


((sxpath `(rdf:RDF rdf:Description ,(select-kids (ntype?? 'dc:title)) *text*))
  doc)

Рис. 23: Вычисление "родного" представления SXPath для пути доступа из рис. 12, с третьим шагом доступа в форме функции Схемы (здесь мы предполагаем, что идентификатор doc связан с SXML-документом из рис. 13)


4.4.1  SXPath как язык запросов

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

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

"Родное" представление для пути доступа в SXPath является S-выражением и может включать в себя произвольные процедуры, определенные на Схеме, в дополнение к набору предопределенных примитивов XPath.

Для иллюстрации этого свойства мы модифицируем наш пример пути доступа, выбирающий заголовок книги. В соответствии с семантикой Dublin Core мы можем предположить, что описание книги всегда имеет ровно одно название (т.е. ровно один элемент dc:title); поэтому мы можем захотеть, чтобы путь доступа возвращал только этот заголовок, а не набор узлов. Далее, предположим, что мы хотим иметь этот заголовок, написанный большими буквами. Мы делаем эти действия пятым специализированным шагом в пути доступа (рис. 24). Будучи вычисленным, этот путь доступа вернет строку "ALGEBRA". Заметим, что в SXML-документе не было текстового узла "ALGEBRA", эта строка была построена как результат запроса на SXPath.


((sxpath
  `(rdf:RDF rdf:Description dc:title *text* ,(lambda (nodeset)
                                               (string-upcase (car nodeset)))))
  doc)

Рис. 24: Запрос на SXPath (здесь мы предполагаем, что идентификатор doc связан с SXML-документом из рис. 13)


Возможность использовать функции языка Схема в качестве предикатов SXPath, и возможность использовать выражения SXPath в функциях языка Схема, делают SXPath поистине расширяемым языком [29]. Пользователь может составлять запросы на SXPath, следуя Рекомендации XPath, -- и в то же время полагаться на полную выразительную мощь языка Схема.

5  Язык XSLT и его реализация функциональными методами

XSLT [28] -- это язык преобразований XML-документов в другой формат, часто с целью представления. Выходными форматами обычно являются XML или HTML.

Несмотря на то, что XML является удобным форматом для внутреннего представления данных, он, однако, не предназначен для наглядного визуального представления. Для отображения информации пользователю электронной библиотеки, XML-данные должны быть преобразованы в другую форму, например, в HTML-документ, который затем может быть просмотрен человеком через браузер. Язык XSLT, разработанный Консорциумом Всемирной Сети (World Wide Web Consortium), является декларативным языком для описания именно таких преобразований. Преобразования на XSL записываются в виде так называемого стиля (stylesheet), который представляется в формате XML.

5.1  Обзор языка XSLT

Язык преобразований XSL (XSLT) -- это одна из наиболее мощных и активно используемых технологий в семействе XML. Язык XSLT получил широкое признание, и активно используется в индустрии, обычно в качестве языка для преобразования XML-документов в другой формат, часто для представления.

Хотя XSLT -- это полный с точки зрения Тьюринга язык программирования, он никогда не позиционировался как язык общего назначения для преобразования XML, равно как язык, в одиночку используемый для разработки законченных XML-приложений. Как явно указывается в Требованиях к XSLT [31], превращение XSLT в язык программирования общего назначения не является явной целью.

Преобразование в языке XSLT выражается в виде правильно сформированного (well-formed) XML-документа [5]. XML-элементы, используемые языком XSLT, отличаются принадлежностью определенному пространству имен XML [18].

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

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

  • Образец -- это выражение на XPath, и он сравнивается с элементами исходного дерева. Узел соответствует конкретному образцу, если узел числится в наборе узлов, полученных в результате обработки данного образца как XPath-выражения в неком возможном контексте. Возможные контексты -- это такие контексты, чьим узлом контекста является проверяемый узел или один из его предков. Для каждого фиксированного узла в исходном дереве, для него будет обрабатываться шаблон, ассоциированный с тем образцом, которому данный узел соответствует.
  • Шаблон обрабатывается для данного конкретного узла, чтобы создать фрагмент в конечном дереве. Шаблон может содержать произвольные XML-данные, которые будут трактоваться как готовые фрагменты конечного дерева; а также элементы из пространства имен XSLT, определяющие инструкции по созданию фрагментов. При обработке шаблона каждая инструкция обрабатывается и заменяется на вычисленный ею фрагмент конечного дерева. Конечное дерево формируется как результат обработки шаблона, соответствующего корневому узлу исходного документа.

Для простых преобразований стиль часто образуется одним шаблоном, который используется как шаблон для всего конечного дерева. Данный подход особенно популярен для преобразования XML-документов, ориентированных на данные (data-centric XML documents).

Рис. 25 дает пример стиля на XSLT. Данный стиль преобразует электронный документ, выраженный в виде XML-данных, в презентационный формат на XHTML. Стиль обозначается глобальным элементом документа xsl:stylesheet из пространства имен XSLT "http://www.w3.org/1999/XSL/Transform". Стиль обычно состоит из нескольких шаблонов XSLT, каждый из который описывается своим собственным элементом xsl:template. Для краткости рис. 25 показывает лишь один такой шаблон. У шаблона в общем случае есть образец, который задается выражением на XPath и представляется как значение атрибута match данного элемента-шаблона. Образец используется для сопоставления с узлами исходного дерева. Шаблон на рис. 25 соответствует всем элементам title, родителями которых является doc. Для каждого элемента, соответствующего образцу, шаблон обрабатывается (относительно данного элемента), чтобы создать фрагмент конечного дерева, в соответствии с содержимым xsl:template. В нашем примере на рис. 25, преобразование рекурсивно применяется к дочерним вершинам элемента (эту работу выполняет инструкция XSLT xsl:apply-templates), и результат включается в заголовок первого уровня. Предполагая, что элемент title, родителем которого является doc, содержит название документа, данный шаблон создаст заголовок первого уровня, содержащий это название.


<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

 <xsl:template match="doc/title">
   <h1>
     <xsl:apply-templates/>
   </h1>
 </xsl:template>

 <!-- Какие-то другие шаблоны -->

</xsl:stylesheet>

Рис. 25: Пример стиля для преобразования электронных документов в XHTML. Показанный шаблон преобразует название документа в заголовок первого уровня.


5.2  STX: реализация XSLT на Схеме

Язык программирования Схема предоставляет практически неограниченные возможности по преобразованию XML/SXML-данных. Известным тому примером является Язык Семантики и Спецификации Стиля Документов (Document-Style Semantics and Specification Language, DSSSL) [33]; и недавно был разработан ряд новых систем, основанных на SXML [17, 34].

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

STX основан на SXSLT [29], и может рассматриваться как его специализация, направленная на совместимость с XSLT. В частности, STX использует алгоритм обхода дерева, разработанный в SXSLT, специализированный и оптимизированный для преобразования XML/SXML-данных в стиле XSLT.

5.2.1  Причины для реализации XSLT на Схеме

XSLT разработан главным образом для тех видов преобразований, которые требуются, когда XSLT используется как часть языка стилей XSL [28]. Для более сложной обработки XML-данных XSLT обычно используется совместно с некоторым языком программирования общего назначения, таким как Java или Python, что приводит к хорошо известной проблеме несоответствия импеданса, из-за разных парадигм программирования и моделей данных.

XSLT может рассматриваться как функциональный язык, и модель данных XML очень близка к S-выражениям Схемы [9]. Схема широко используется как язык расширения и как язык обработки XML, что делает Схему естественным кандидатом для расширения XSLT.

XSLT -- это полный с точки зрения Тьюринга язык программирования, и многие впечатляющие примеры доказывают его применимость для целого ряда самых разнообразных задач. Тем не менее, большинство "жизненных" приложений используют небольшое подмножество XSLT для относительно простых преобразований XML-документов. Некоторые учебники по XSLT [35] даже утверждают, что лишь нескольких команд XSLT достаточно для большинства практических нужд.

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

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

5.2.2  Архитектура STX

XSLT использует слегка модифицированную модель данных XPath [8], которая может рассматриваться как представление Информационного Пространства XML Infoset [6] в виде помеченного дерева узлов. STX основан на модели данных SXML, поскольку SXML является реализацией Информационного Пространства XML в виде S-выражений.

SXML изначально разрабатывался с целью обеспечить эффективное вычисление запросов на XPath. Для SXML существует формальная спецификация [9], которая дополняется набором реализованных на Схеме основных XML-технологий. Две из этих технологий, а именно, XML-парсер SSAX и язык запросов к SXML SXPath, составляют ядро STX. И SXML, и модель данных XPath основаны на Информационном Пространстве XML, представленном как древовидная структура. Сходства между этими моделями данных очевидны [36], и их взаимное отображение друг на друга прямолинейно, что значительно упрощает интеграцию. По этим причинам STX основан на модели данных SXML.

Сопоставление образцов узлу производится в STX в соответствии с Рекомендацией XSLT. Правила шаблонов определяют вершины, к которым они применяются, с помощью образца, который представляет собой выражение на XPath. STX использует прямолинейный алгоритм сопоставления, основанный на SXPath -- реализации XPath на Схеме (см. подраздел 4.2). Сопоставление в STX производится за счет применения SXPath к образцу; преобразования образца в функцию, которая выбирает множество узлов; и последовательного применения этой функции к сопоставляемому узлу и к его родителям, до тех пор, пока сопоставляемая вершина не окажется членом результирующего множества узлов, или не будет достигнута корневая вершина. В первом случае узел соответствует образцу, во втором случае -- нет.

Целостная интеграция XSLT и Схемы была основной целью при разработке STX. Данная цель достигается использованием общей модели данных и вычислительной парадигмы для обоих компонентов STX.

Шаблоны XSLT являются, в сущности, чистыми функциями -- каждый шаблон определяет фрагмент конечного дерева как функцию от фрагмента исходного дерева, и не производит побочных эффектов [37]. STX преобразует шаблоны в списки функций Схемы. В каждом списке, первая функция конструируется с помощью SXPath и используется для сопоставления шаблона узлам; вторая представляет собой функцию для преобразования в соответствии с шаблоном. Эта функция для преобразования может быть описана на Схеме (в случае stx:template), так же как и на XSLT (в случае xsl:template). В этом контексте, XSLT может рассматриваться как "синтаксический сахар" для кода на Схеме, в который она преобразуется. Идея иллюстрируется рисунком 26.



Рис. 26: Модель обработки в STX. STX принимает стили, описанные на XSLT, на Схеме, а также на их комбинации.


STX подражает простому "презентационному" подмножеству XSLT. Менее популярные конструкции XSLT не поддерживаются, но могут быть заменены шаблонами на Схеме. Эта категория состоит, в основном, из "программистских" конструкций, таких как инструкции условной обработки, обработка переменных и параметров. Мы полагаем, что эти конструкции больше соответствуют языку программирования (Схема), чем языку стилей (XSLT).

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

6  Язык XLink и его реализация функциональными методами

Современные электронные библиотеки хранят разнообразные виды информации: текст, картинки, звук, видео и пр. В контексте приложений электронных библиотек нам часто приходится иметь дело с громадными ресурсами, которые характеризуются большим многообразием, многочисленными форматами представления, способами обработки и т.п. Эти обстоятельства делают затруднительным (или даже невозможным) адекватное представление таких данных в виде одной информационной единицы (например, в виде единого файла). Как правило, данные электронных библиотек должны представляться в виде совокупности многих ресурсов. Поскольку эти ресурсы по семантике связаны между собой, они не должны существовать как совершенно независимые друг от друга, и часто желательно специфицировать их родство с использованием связей. Язык XML Linking Language (XLink) [30], разработанный Консорциумом Всемирной Сети, может быть эффективно применен для данной цели: это язык описания ссылок между ресурсами с использованием XML и отдельного пространства имен.

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

6.1  Обзор языка XLink

XML Linking Language (XLink) -- это язык описания межресурсных связей с помощью XML.

XLink обеспечивает полную функциональность гиперссылок HTML, и гораздо большее: он позволяет устанавливать отношение связи между более чем двумя ресурсами, ассоциировать различные метаданные со ссылками, соединять ресурсы без их модификации [32].

Язык XLink позволяет соединять произвольные ресурсы, а не только XML-документы. Понятие ресурса определяется в IETF RFC 2396 как любая адресуемая единица информации или сервиса. Если ресурс представляет собой правильно сформированный (well-formed) XML-документ, то спецификация XLink считает ресурсом также любую часть этого документа, определяемую идентификатором фрагмента на языке XML Pointer Language (XPointer). Подобный идентификатор фрагмента может дополнять адрес документа, задаваемый с помощью Унифицированного Идентификатора Ресурса (URI).

Язык XLink вводит два типа ссылок.

  1. Расширенная ссылка (extended link). Расширенные ссылки выражают полную функциональность языка XLink, такую как входящие (inbound) и сторонние (third-party) арки, а также объединяют произвольное количество участвующих в них ресурсов. Участвующие ресурсы могут быть любой комбинацией локальных и удаленных.

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

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

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

    В языке XLink определяется способ, когда расширенной ссылке добавляется специальная семантика для указания на ссылочные базы (linkbases). Когда ссылка используется в таком назначении, она помогает XLink-приложению обрабатывать другие ссылки.

    Рис. 27 показывает пример использования расширенной ссылки языка XLink. В этом примере мы соединяем книгу из электронной библиотеки, автора книги и издательство. Мы даем описание автора в локальном ресурсе языка XLink, т.е. описание целиком располагается внутри ссылочного элемента. Книга и издательство -- это удаленные ресурсы языка XLink, потому что на них ссылаются при помощи Унифицированных Идентификаторов Ресурсов. Каждый из трех ресурсов помечен собственной меткой (label). Эти метки используются при описании переходов. Мы определяем два перехода: от автора к книге и от книги к издательству. Каждый переход описывается своим собственным элементом типа дуга (arc). Заметим, что дуга, ведущая от книги к издательству, соединяет два удаленных ресурса.


    <!--Расширенная ссылка языка XLink. Элемент может носить произвольное имя-->
    <MyExtendedLink xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended">
    
      <!--Элемент типа ресурс. Специфицирует локальный (в терминах XLink) ресурс-->
      <author xlink:type="resource" xlink:label="A">
        <!--Некоторая разметка, относящаяся к локальному ресурсу-->
        <name>John</name>
        <surname>Smith</surname>
      </author> 
    
      <!--Элемент типа локатор. Адресуется к удаленному ресурсу по его URI-->
      <book xlink:type="locator"  xlink:label="B"
            xlink:href="http://library.com/book.xml"/>
    
      <publisher xlink:type="locator"  xlink:label="P"
                 xlink:href="http://publisher.com"/>
    
      <!--Элемент типа дуга. Определяет переход между ресурсами с метками "A" и "B"-->
      <MyArcElement xlink:type="arc" xlink:from="A" xlink:to="B"/>
    
      <MyArcElement xlink:type="arc" xlink:from="B" xlink:to="P"/>
        
    </MyExtendedLink>

    Рис. 27: Пример расширенной ссылки языка XLink. Ссылка устанавливает отношение связи между книгой (удаленный ресурс), ее автором (локальный ресурс) и издательством (удаленный ресурс).


  2. Простая ссылка (simple link) -- это ссылка, которая ассоциирует в точности два ресурса -- один локальный и один удаленный; с аркой, идущей от первого ко второму. Таким образом, простая ссылка всегда является исходящей (outbound). Исходящая связь, в которой участвует ровно два ресурса, является наиболее распространенной (например, в эту категорию попадают ссылки A и IMG языка HTML). Поскольку простые ссылки предоставляют значительно меньше функциональных возможностей, чем расширенные ссылки, у простых ссылок нет какой-либо специальной внутренней структуры.

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

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

    Иллюстрация простой ссылки приведена на рис. 28. Она ведет к содержанию некоторой книги, и напоминает гиперссылку A языка HTML. Однако, в отличие от гиперссылки HTML, простая ссылка языка XLink не требует именованного якоря для адресации к фрагменту документа, поскольку идентификатор фрагмента на языке XPointer предоставляет более гибкие возможности.


    <!--Простая ссылка языка XLink. Элемент может носить произвольное имя-->
    <MySimpleLink
      xmlns:xlink="http://www.w3.org/1999/xlink"
      xlink:type="simple"
      xlink:href="http://library.com/book.xml#xpointer(doc/contents)">
       Go to table of contents
       <!--Какая-то более сложная разметка может быть описана здесь-->
    </MySimpleLink>

    Рис. 28: Пример простой ссылки языка XLink


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

6.2  Реализация XLink на Схеме: SXLink

SXLink -- это реализация XLink и Интерфейс Прикладного Программирования (Application Program Interface, API) на языке функционального программирования Схема. SXLink полностью поддерживает синтаксис и семантику XLink, и предоставляет Интерфейс Прикладного Программирования для обработки множества документов, соединенных с помощью XLink.

6.2.1  Причины для реализации XLink на Схеме

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

Такой проблемы нет в Схеме, так как S-выражения создают единую среду для представления документов с элементами XLink -- в виде SXML. Возможность использования единого языка высокого уровня для обработки XML-данных и реализации приложений является одним из важных достоинств подхода, использованного в SXLink.

Кроме того, обработка документов, содержащих элементы XLink, является задачей обхода или преобразования деревьев. Данная задача прекрасно укладывается на парадигму обработки иерархических S-выражений, т.е. при этом могут использоваться типовые алгоритмы и инструментальные средства языка Схема.

6.2.2  Архитектура SXLink

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

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

Как обсуждалось в подразделе 6.1, спецификация XLink фокусируется в основном на предоставлении структур данных для описания ссылок, и не предоставляет никакого Интерфейса Прикладного Программирования для их обработки. Мы разработали такой Интерфейс Прикладного Программирования и реализовали его в SXLink. Стоит отметить следующие операции, предоставляемые системой SXLink:

  1. Автоматическая валидация ссылок. Эта операция позволяет убедиться, является ли каждая ссылка XLink семантически осмысленной, т.е.
    • все ресурсы, участвующие в ссылке, существуют;
    • все части ресурсов, определяемые с помощью идентификаторов фрагментов на языке XPointer, доступны;
    • (если требуется) роли и/или роли дуг в XLink представляют собой Унифицированные Идентификаторы существующих ресурсов.

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

  2. Разрешение ссылок. Данная операция преобразует все ссылки языка XLink в исходящие. Результирующий документ (называемый "разрешенным документом") эквивалентен исходному с точки зрения семантики XLink, но становится проще с точки зрения его последующей обработки другими приложениями, потому что для исходящей ссылки легко определить начало перехода. Например, разрешенный документ затем может быть легко преобразован в HTML и просмотрен с помощью браузера.

  3. Включение вершин. Данная операция является дальнейшим развитием разрешения ссылок. Включение вершин заменяет каждый узел в документе, являющийся исходным ресурсом (starting resource) на соответствующий этой ссылке целевой ресурс (ending resource). Данная операция особенно полезна, когда целевые ресурсы ссылок описывают некоторую детализированную информацию, и желательно создать новый документ, в котором вся эта информация включена в явном виде.

SXLink обеспечивает дополнительную гибкость рассмотренных операций за счет использования функций языка Схема в качестве объектов первого класса.

6.3  Функциональная интеграция XSLT и XLink

Данный подраздел описывает несколько сценариев интеграции XSLT и XLink, целью которой является повышение выразительной мощи и гибкости средств преобразования и связывания XML-данных. Данный подход к интеграции XSLT и XLink значительно выигрывает при реализации его с использованием функциональных методов, как дальнейшее расширение STX и SXLink.

6.3.1  Соединение документа и его стиля

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

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

  • в стиле XSLT,
  • или в XML-документе, для которого этот стиль разработан,
  • или даже как отдельный XML-документ (называемый ссылочной базой).

Процессор XSLT, расширенный поддержкой XLink, сможет руководствоваться этими ссылками для выбора подходящего стиля XSLT для данного XML-документа. Подобный интеллектуальный процессор XSLT может быть удобно реализован как интеграция STX и SXLink, поскольку они оба базируются на общей модели данных (SXML) и общих алгоритмах (таких как SXPath).

6.3.2  Преобразование XSLT в качестве представления целевого ресурса при переходе по ссылке языка XLink

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

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

Спецификация XLink вводит глобальный атрибут arcrole в пространстве имен XLink, предназначенный для описания семантики целевого ресурса ссылки относительно ее исходного ресурса. Атрибут arcrole соответствует понятию свойства в Модели Описания Ресурсов [23], где роль может быть проинтерпретирована как утверждение о том, что "исходный-ресурс имеет роль-дуги целевой-ресурс". В соответствии со спецификацией XLink [30], значением атрибута arcrole должен быть Унифицированный Идентификатор Ресурса, идентифицирующий некоторый ресурс, который описывает соответствующее свойство.

Мы предлагаем одним из возможных применений атрибута XLink arcrole -- идентификация стиля XSLT. Если атрибут arcrole идентифицирует стиль, то этот стиль следует использовать для построения представления для целевого ресурса ссылки в момент перехода по ней.

Данная идея иллюстрируется рисунком 29. Ссылка XLink ведет к книге в электронной библиотеке, и атрибут arcrole идентифицирует стиль, определяющий представление для книги, которое будет получено при переходе по ссылке. Например, стиль может преобразовывать книгу в HTML. Необходимо отметить, что получаемое представление зависит от той ссылки, переход по которой был осуществлен. Другая ссылка, ведущая к той же книге, возможно, будет использовать другой стиль XSLT, и таким образом различные представления одной и той же книги будут получены при переходе по разным ссылкам. Подобное поведение полностью соответствует семантике атрибута arcrole, определенной в спецификации XLink.


<link-to-a-book
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xlink:type="simple"
  xlink:href="http://library.com/book.xml"
  xlink:arcrole="http://library.com/transform.xsl"/>

Рис. 29: Использование роли дуги для задания стиля XSLT, который служит в качестве представления для целевого ресурса (книги в электронной библиотеке)


SXLink может быть легко расширен предложенной функциональностью, поскольку SXLink распознает полный синтаксис XLink и, таким образом, атрибут arcrole, и поскольку интеграция SXLink и STX является естественной и прямолинейной.

6.3.3  XSL-преобразование нескольких связанных XML-документов

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

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

А именно, мы предлагаем добавить одну дополнительную ось в язык XML Path (который используется как часть XSLT). Назовем ее ось traverse (перейти), и она будет содержать все узлы, к которым можно перейти по ссылкам языка XLink из контекстного узла. С использованием этой дополнительной оси мы в понятной и краткой форме сможем выражать XSL-преобразования, включающие в себя несколько соединенных документов.

Рис. 30 иллюстрирует идею подобного расширенного шаблона XSL, который преобразует некоторую библиографию, выраженную на XML. Ось traverse может использоваться в образце шаблона, чтобы указать, что шаблон соответствует любому узлу (node) в библиографии, который является ссылкой XLink на книгу (book). Заметим, что книга может располагаться в другом XML-документе. В теле шаблона ось traverse позволяет нам сконструировать текст по информации из другого документа (xsl:value-of), и даже применять шаблоны к фрагменту удаленного документа (xsl:apply-templates).


<xsl:template match="node()[traverse::book]">
  ...
  <xsl:value-of select="traverse::book/title"/>
  ...
  <xsl:apply-templates select="traverse::book/chapter/section"/>
  ...
</xsl:template>

Рис. 30: Шаблон XSL, расширенный поддержкой XLink


7  Заключение

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

Информация, содержащаяся в правильном XML-документе, описывается спецификацией XML Information Set. XML, DOM, модель данных XPath и пр. представляют собой различные реализации XML Infoset. В данных материалах рассматривался другой пример XML Infoset -- SXML -- имеющий вид S-выражения и, следовательно, легко и естественно обрабатываемый языком Схема.

Пространства имен, поддерживаемые SXML, могут рассматриваться как надмножество пространств имен в XML. Помимо поддержки префиксов пространства имен, SXML обеспечивает уникальную возможность непосредственного использования Унифицированных Идентификаторов Ресурсов в полных именах, а также механизм идентификаторов пространств имен.

SXML изначально разрабатывался с целью обеспечить эффективное вычисление выражений XPath. SXPath -- полностью соответствующая Спецификации реализация XPath на языке функционального программирования Схема -- расширяет XPath возможностями языка запросов и органично интегрирует XPath со Схемой.

Помимо эффективного вычисления выражений XPath, функциональные методы прекрасно подходят также для преобразования и связывания XML-данных. В данных материалах мы рассмотрели некоторые способы применения функциональных методов для реализации инструмента XML-преобразований STX, развивающего основные идеи языка XSLT, и XLink-процессора SXLink. Языки XSLT и XLink могут значительно выиграть от их взаимной интеграции, и объединение STX и SXLink с использованием функциональных методов предоставляет практический подход к подобной интеграции.

Рассмотренная технология может быть использована для построения основанных на XML электронных библиотек, в особенности "легковесных" [38].

Список литературы

[1]
Ioannis Papadakis, Vasillios Chrissikopoulos. A Digital Library Framework based on XML.
http://citeseer.nj.nec.com/543571.html

[2]
Cuneiform Digital Library Initiative to Use XML Encoding for Third Millennium Texts.
http://xml.coverpages.org/ni2001-11-06-c.html

[3]
Лисовский К. Ю. Разработка XML-приложений на языке Scheme. Программирование, выпуск 28, номер 4, 2002.
http://www.maik.rssi.ru/journals/procom.htm

[4]
Revised5 Report on the Algorithmic Language Scheme. Kelsey R., Clinger W., Rees J. (Editors). Higher-Order and Symbolic Computation, Vol. 11, No. 1, September, 1998 and ACM SIGPLAN Notices, Vol. 33, No. 9, October, 1998.
http://www.schemers.org/Documents/Standards/R5RS/

[5]
Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October 2000.
http://www.w3.org/TR/REC-xml

[6]
XML Information Set. W3C Recommendation 24 October 2001.
http://www.w3.org/TR/xml-infoset/

[7]
Document Object Model (DOM) Level 2 Core Specification Version 1.0. W3C Recommendation, November 13, 2000.
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113

[8]
Язык XML Path (XPath) Версия 1.0. Рекомендация W3C от 16 Ноября 1999.
http://www.xpath.info/docs/REC-xpath-19991116-ru.html

[9]
Oleg Kiselyov. SXML, Revision 2.5. August 9, 2002.
http://okmij.org/ftp/Scheme/SXML.html

[10]
John McCarthy. Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I. Comm. ACM, 3(4):184-195, April 1960.
http://www-formal.stanford.edu/jmc/recursive/recursive.html

[11]
James Clark, Makoto Murata, editors. RELAX NG Specification. OASIS, 2001.
http://www.oasis-open.org/committees/relax-ng/spec-20011203.html

[12]
James Clark. The Design of RELAX NG. December 6, 2001.
http://www.thaiopensource.com/relaxng/design.html

[13]
Oleg Kiselyov. Functional XML parsing framework: SAX/DOM and SXML parsers with support for XML Namespaces and validation. September 5, 2001.
http://www.okmij.org/ftp/Scheme/SSAX.scm

[14]
A Triumph of Simplicity: James Clark on Markup Languages and XML. Dr. Dobbs Journal, July, 2001.
http://www.ddj.com/articles/2001/0107/0107e/0107e.htm

[15]
St.Laurent S. XML Elements of Style. McGraw-Hill, 2000.

[16]
Lisovsky K. Scheme program source code as a semistructured data. 2nd Workshop on Scheme and Functional Programming. Florence, September 2001.
http://kaolin.unice.fr/Scheme2001/article/lisovsky.ps

[17]
Kiselyov O. XML and Scheme. Workshop on Scheme and Functional Programming 2000, Montreal, 2000.
http://www.okmij.org/ftp/Scheme/SXML-short-paper.html

[18]
Namespaces in XML. World Wide Web Consortium 14-January-1999.
http://www.w3.org/TR/REC-xml-names/

[19]
James Clark. XML Namespaces. February 4, 1999.
http://www.jclark.com/xml/xmlns.htm

[20]
Request for Comments: 2413. Dublin Core Metadata for Resource Discovery. Network Working Group. September 1998.
http://rfc-2413.rfclist.org/rfc-2413.htm

[21]
Request for Comments: 2731. Encoding Dublin Core Metadata in HTML. Network Working Group. December 1999.
http://www.ietf.org/rfc/rfc2731.txt

[22]
Eric Miller. An Introduction to the Resource Description Framework. D-Lib Magazine. May 1998.
http://www.dlib.org/dlib/may98/miller/05miller.html

[23]
Resource Description Framework (RDF): Concepts and Abstract Syntax. W3C Working Draft 23 January 2003.
http://www.w3.org/TR/rdf-concepts/

[24]
RDF/XML Syntax Specification (Revised). W3C Working Draft 23 January 2003.
http://www.w3.org/TR/rdf-syntax-grammar

[25]
Stefan Kokkelink, Roland Schwanzl. Expressing Qualified Dublin Core in RDF / XML. DCMI Proposed Recommendation. 2002-04-14.
http://dublincore.org/documents/2002/04/14/dcq-rdf-xml/

[26]
Когаловский М.Р. Глоссарий по технологиям платформы XML. Версия 3 (15-12-2002).
http://www.elbib.ru/index.phtml?page=elbib/rus/methodology/xmlbase/glossary_XML

[27]
XPath Location Paths. W3 Schools.
http://www.w3schools.com/xpath/xpath_location.asp

[28]
Язык преобразований XSL (XSLT) Версия 1.0. Рекомендация W3C от 16 ноября 1999.
http://www.rol.ru/news/it/helpdesk/xslt01.htm

[29]
O. Kiselyov, K.Lisovsky. XML, XPath, XSLT Implementation as SXML, SXPath and SXSLT. International Lisp Conference ILC 2002, San Francisco. October, 2002.
http://www.okmij.org/ftp/papers/SXs.pdf

[30]
XML Linking Language (XLink) Version 1.0. W3C Recommendation 27 June 2001.
http://www.w3.org/TR/xlink/

[31]
XSLT Requirements Version 2.0. W3C Working Draft, February 2001.
http://www.w3.org/TR/2001/WD-xslt20req-20010214

[32]
XML XLink Requirements Version 1.0. W3C Note 24-Feb-1999.
http://www.w3.org/TR/NOTE-xlink-req/

[33]
Document Style Semantics and Specification Language (DSSSL). ISO/IEC 10179:1996(E).
ftp://ftp.ornl.gov/pub/sgml/WG8/DSSSL/dsssl96b.pdf

[34]
Oleg Kiselyov, Shriram Krishnamurthi. SXSLT: Manipulation Language for XML. Practical Aspects of Declarative Languages, 5th International Symposium, PADL 2003.
http://link.springer.de/link/service/series/0558/bibs/2562/25620256.htm

[35]
D. Jacobs. Rescuing XSLT from Niche Status. http://www.xfront.com/rescuing-xslt.html

[36]
Kirill Lisovsky. STX: Scheme-enabled XSLT processor.
http://www.pair.com/lisovsky/transform/stx/

[37]
M. Kay. What kind of language is XSLT? February 2001.
http://www-106.ibm.com/developerworks/xml/library/x-xslt/

[38]
Журавлева О.В., Лисовский К.Ю., Томусяк Г.С., Томусяк Э.С. Функциональные методы обработки слабоструктурированных данных и их применение для построения электронных библиотек. Сборник трудов Третьей Всероссийской конференции по электронным библиотекам. КНЦ РАН, Петрозаводск, сентябрь 2001.
http://www.pair.com/lisovsky/misc/biblio/index.html


Поиск:
Последнее обновление страницы было произведено: 2004-01-05

Все предложения и пожелания по содержанию и структуре портала направляйте по адресу: rdlp@iis.ru