XML основывается на принципах и соглашениях двух существующих языков разметки, XML и SGML, каждый из которых получил широкое распространение и успешно использовался для решения своего круга задач.
Несмотря на то, что идеи обобщенной разметки начали появляться еще в 60-х годах, SGML (standard generalized markup language, стандартный язык обобщенной разметки) был ратифицирован Международной Организацией Стандартизации (ISO) только в 1986 году. Возможно, будет показательным тот факт, что SGML не требовал изменений в течение, практически, 10 лет — настолько мощным инструментом он был.
Вместе с тем, на определенном этапе мощь SGML стала становиться препятствием — этот язык был настолько сложен, что поддержка в приложениях даже основного его подмножества оказалась непростой задачей. Это сказывалось на скорости разработки, стабильности и стоимости приложений, и потому, все больше и больше экспертов высказывались за упрощение этого языка.
Примерно в то же время произошел квантовый скачок в другой области информационных технологий. Развитие сетевых технологий вывело инфраструктуру обмена информации на качественно новый уровень, произведя на свет глобальную сеть Интернет. Интернет, в свою очередь, стал платформой для обмена гипертекстовыми документами, которые также нуждались в простом стандартном языке разметки для базового форматирования текста, создания таблиц и гиперссылок. Для этих целей был разработан HTML — язык разметки гипертекста (hypertext markup language).
HTML основывался на синтаксисе SGML, принципы этой технологии были практически проигнорированы. Только намного позже HTML стал SGML- совместимым языком. Ограниченность и нерасширяемость HTML вела к тому, что производители браузеров (программ просмотра) вводили собственные, в большинстве случаев несовместимые, расширения, что в итоге привело к довольно плачевной ситуации в этой области.
Потребность в улучшении HTML совпала с потребностью в упрощении SGML. В 1996 году Консорциум W3 (World Wide Web Consortium, W3C) поддержал группу Web SGML Activity, задачей которой было создание нового языка разметки, более мощного, чем HTML, но более простого, чем SGML.
Разработка началась с определения десяти положений, которым должен был соответствовать новый язык. Хотя эти положения и не являются определяющими для уже созданного языка, они все еще включаются в официальную спецификацию XML (п. 1). Думается, будет довольно интересно сравнить первоначальные устремления с тем, что получилось на самом деле. Попытаемся подробнее рассмотреть десять положений XML.
1. XML должен напрямую использоваться в сети Интернет. Возможно, XML еще долго не будет использоваться в Интернет, как основной язык разметки (сказывается огромная инертность технологий), но, во всяком случае, авторы попытались по максимуму учесть в XML особенности языка HTML.
2. XML должен поддерживать разнообразные приложения. Как уже было описано выше, XML можно использовать в самых разных областях — тут сказывается мощь абстракции, которую предоставляет древовидные представления данных.
3. XML должен быть совместим с SGML. XML был разработан, как подмножество языка SGML, и для его обработки можно использовать любые SGML-продукты.
4. Разработка программ для обработки XML-документов не должна быть сложной задачей. Конструктивный синтаксис XML намного проще, по сравнению с SGML, а значит, XML-инструменты также проще разрабатывать и использовать в своих решениях.
5. Количество необязательных особенностей XML должно быть как можно меньше, в идеале их не должно быть вовсе. Сложно сказать, насколько это положение было выполнено — ведь большинство особенностей в XML являются необязательными. С другой стороны, в XML, как правило, существует только один способ добиться желаемого эффекта — в этом смысле опций, действительно, немного.
6. XML-документы должны быть понятны человеку, и при этом достаточно ясны. Как мы уже могли убедиться, XML-документы имеют простую и понятную форму.
7. XML должен быть разработан быстро. Разработчикам понадобилось два года — с 1996 по 1998, чтобы создать XML — значительный срок для довольно простого языка.
8. Спецификация XML должна быть формальной и лаконичной. Синтаксис языка XML однозначно определяется EBNF-правилами, а сама спецификация не имеет двояких толкований.
9. XML-документы должны легко создаваться. Поскольку UTF-8, основная форма кодирования XML-документов, совместима с ASCII, для редактирования XML-документов можно использовать все множество инструментов для работы с обычными текстовыми файлами.
10. Лаконичность разметки XML-документов не является важной. Язык SGML позволял авторам документов опускать части разметки в случаях, когда из контекста ясно, что там должно быть. Подобный принцип был использован в HTML, где в некоторых случаях можно опускать закрывающие теги, например,
. Для того, чтобы облегчить обработку, XML не позволяет такой вольности.Главную роль в создании XML приписывают техническому гуру из фирмы Sun, Йону Босаку (Jon Bosak). Босак и его команда сделали с SGML примерно то же, что когда-то сделала команда, создававшая язык Java с языком С++. Язык был упрощен, сложные и редко использующиеся его особенности были упразднены. Первая спецификация языка, редакторами который были Тим Брэй (Tim Bray) и С.М. Шперберг-МакКвин (С.М. Sperberg-McQueen), в общей сложности насчитывала 26 страниц, что примерно в 20 раз меньше по объему стандарта SGML.
В октябре 2000 года с небольшими изменениями была принята вторая редакция спецификации языка XML. Судя по всему, язык оказался настолько удачным, что пройдет довольно значительное время прежде, чем он будет изменен.
Будущее XML практически гарантировано. Несмотря на всю поднятую маркетинговую шумиху, в которой XML — не более чем "buzzword", расхожее словечко, нельзя игнорировать два следующих обстоятельства. Во-первых, без сомнения, существует огромная потребность в простом языке обобщенной разметки, и, во-вторых, у XML просто нет конкурентов. Большие компании уже приняли XML, как стандартное средство, в составе многих своих решений, и вряд ли какая другая технология сможет в скором времени вытеснить этот язык.
Вместе с тем, было бы ошибкой считать, что XML пришел на замену HTML и SGML. Совсем нет — XML занимает те ниши, которые ранее были недоступны этим двум языкам. В информационном мире всегда будет место для каждого из них, хотя, вполне закономерно ожидать, что XML-технологии получат со временем гораздо более широкое распространение, чем HTML и SGML вместе взятые.
Глава 2Введение в XSLT
Документ = Данные + Структура
В предыдущей главе мы подробно разобрали синтаксис XML, являющийся ключом к пониманию сути XML, которая состоит в том, что простых текстовых меток вполне достаточно, чтобы явно выделить в документе сколь угодно сложную структуру.
По большому счету, здесь XML заканчивается. Это не язык программирования, не язык операторов и функций, но язык структуры документа. Язык для простого и при этом очень четкого ее описания.
Важность роли, которую играет структура данных в программировании, сложно переоценить. В классической цитате Н. Вирта "Алгоритмы + Структуры данных = Программы", датированной 1976 годом, спустя четверть века "плюс" следует скорее трактовать, как знак умножения, но принцип остался верен: структура данных имеет ничуть не меньшее значение, чем алгоритм, который ее обрабатывает.
Успех XML можно, пожалуй, объяснить другим уравнением:
Документ = Данные + СтруктураВ примитивной трактовке это означает, что для того, чтобы получить программу, к документам остается только дописать алгоритмы — данные и структура уже имеются. Если присмотреться более внимательно, можно заметить, что структура данных в равенстве Вирта и структура, которая является одной из составляющих документа, на самом деле могут быть (и, как правило, бывают) очень разными. Положение усугубляется еще и тем, что для одних и тех же данных можно выдумать великое множество типов структур, мало совместимых между собой. Таким образом, для того, чтобы эффективно использовать XML, во многих случаях необходимо уметь преобразовывать структуру XML-документов.
Как оказалось, традиционные процедурные языки программирования плохо подходят для решения этой задачи: слишком громоздкими были в них программы для преобразования структуры. Объяснить это легко — большинство языков оперировали данными и к арифметике структур документов были мало приспособлены. Проблема требовала более гибкого и мощного решения, и этим решением стал язык XSLT.
XSLT означает extensible Stylesheet Language for Transformations, что на русский язык традиционно переводится как "расширяемый язык стилей для преобразований". Название это скорее историческое, нежели смысловое — работа над XSLT была инициирована проектом XSL — extensible Stylesheet Language (расширяемым языком стилей).
Спецификация XSLT гласит, что это язык для преобразования одних XML-документов в другие XML-документы. Вне всякого сомнения, таковой и была изначальная идея XSLT. Очевидно, в процессе разработки язык перерос ее и теперь уместнее согласиться с редактором новой версии языка, Майклом Кеем (Michael Kay) в том, что XSLT — это язык для преобразования структуры документов.
XSLT как язык
По большому счету, любое преобразование можно условно поделить на три составляющие:
□ обращение к преобразуемому объекту;
□ создание результата преобразования;
□ логика, связывающая первые два действия и направляющая процесс преобразования.
Применительно к преобразованию XML-документов первая подзадача означает получение информации, которую этот документ содержит — в том числе и информации о структуре, которая является неотъемлемой его частью. Обращение в данном случае имеет несколько смыслов, в том числе — опрашивать, делать запросы, вычислять, выбирать; в общем смысле — задавать о документе вопросы и получать на них ответы. Для этой цели в XSLT служит язык, называемый XPath — язык путей в ХМL-документах (от англ. XML Path Language). Как мы увидим, XPath является лаконичным, но при этом чрезвычайно мощным средством обращения к XML-документам (а также к их частям). Роль XPath в XSLT так велика, что их можно было бы считать единым целым, если бы только XPath не использовался также и в других языках, предназначенных для работы с XML.
Вторая и третья условные части преобразования являются прерогативой самого XSLT. XSLT — это XML-язык в полном смысле этого слова: программы на XSLT (мы будем называть их преобразованиями сообразно их предназначению) являются хорошо оформленными (well-formed) XML-документами. XSLT также использует пространства имен; практически все имена, встречающиеся в XSLT, как-то: имена переменных, шаблонов, форматов и так далее — рассматриваются как расширенные имена, характеризуемые локальной частью вкупе с URI — уникальным идентификатором пространства имен.
В отличие от традиционных императивных языков программирования, преобразование в XSLT не является последовательностью действий, которую необходимо выполнить для достижения результата. Преобразование — это набор шаблонных правил, каждое из которых определяет процедуру обработки определенной части документа. Иными словами, преобразование в XSLT объявляет, декларирует правила преобразования — правила, применяя которые к входящему документу, XSLT-процессор в конечном итоге генерирует выходящий документ, который и является целью преобразования.
В качестве первого примера XSLT-преобразования, который будет приведен в этой книге, мы рассмотрим классическую программу
"Hello, world!"
. Листинг 2.1 показывает XSLT-интерпретацию "Hello, world!"
, когда мы преобразуем документHello, world!
в документ вида:
Hello, world!
Листинг 2.1. Преобразование "Hello, world!"
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
Исходный код, представленный выше, является хорошо оформленным XML-документом. Корневым его элементом является элемент
xsl:stylesheet
, который и обозначает преобразование. Атрибут version
указывает на версию языка XSLT, в соответствии с которой был построен этот документ; помимо этого в элементе xsl:stylesheet
объявляется пространство имен с префиксом xsl
, которому соответствует URI "http://www.w3.org/1999/XSL/Transform"
. Все элементы преобразования, принадлежащие пространству имен с этим URI, будут восприняты процессором, как принадлежащие языку XSLT.Элемент
xsl:stylesheet
имеет один-единственный дочерний элемент xsl:template
, который и задает правило преобразования. Атрибут match
указывает, что это правило должно обрабатывать элемент msg
. Содержимое xsl:template
является телом шаблона. Оно выполняется тогда, когда сам шаблон применяется к некоторой части документа. В данном случае тело шаблона будет выполнено, когда само правило будет применяться к элементу msg
.Телом шаблона является элемент
message
. В терминах XSLT, этот элемент является литеральным элементом результата: он не принадлежит пространству имен XSLT и поэтому при обработке будет просто скопирован в результирующий документ. Содержимое этого элемента будет также обработано и включено в его сгенерированную копию.Содержимым элемента
message
является элемент xsl:value-of
, который, в отличие от message
принадлежит XSLT. Элемент xsl:value-of
вычисляет XPath-выражение, заданное в его атрибуте select
, и возвращает результат этого вычисления. XPath-выражение, "."
, указанное в select
, возвращает ту самую часть узла, которая обрабатывается в данный момент, иначе говоря — элемент msg
.Переводя на русский язык все вышеперечисленное, можно сказать, что приведенное преобразование содержит единственное правило: если в документе встретится элемент
msg
, создать в выходящем документе элемент message
и включить в него содержимое элемента msg
.Синтаксис XSLT, являющийся чистым XML, может показаться для языка программирования не совсем обычным, однако, как показывает практика, вряд ли какой другой синтаксис был бы более удобным. В конце концов, XSLT — это, прежде всего преобразование XML-документов, и уж на чем, как не на XML описывать правила этого преобразования. Кроме того, XML- формат самого преобразования позволяет использовать для его представления те же модели данных, что и для преобразуемых документов.
Совсем иным является язык XPath, который представлен в нашем примере лаконичным выражением
"."
. XPath не придерживается XML-синтаксиса, напротив, он скорее похож на синтаксис путей в операционных системах — в главе 4 мы покажем, насколько верно это сравнение.В приведенном преобразовании участвовала и третья синтаксическая конструкция, которая называется в XSLT паттерном (от англ. pattern — образец). Паттерн
msg
, заданный в атрибуте match
элемента xsl:template
указывает, какая именно часть XML-документа должна быть обработана этим правилом. Синтаксически паттерны являются XPath-выражениями (но не наоборот), однако смысл их различается. XPath-выражения вычисляются и возвращают результат, паттерны же просто устанавливают соответствие некоторому образцу. В нашем преобразовании паттерн msg
указывает, что шаблон должен обрабатывать только элементы msg
и никакие другие.Каждое из шаблонных правил может вызывать другие шаблонные правила — в этом случае результат выполнения вызванных шаблонов включается в результат выполнения шаблона, который их вызывал. Для того чтобы продемонстрировать этот принцип мы немного перепишем шаблон
"Hello, world!"
с тем, чтобы он возвращал результат в виде HTML-документа.Листинг 2.2. Преобразование "Hello, world!"' с результатом в HTML
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
Message
Результат применения этого преобразования к документу
Hello, world!
иллюстрирует листинг 2.3.
Листинг 2.3. Результат выполнения преобразования
Message
Hello, world!
В это преобразование мы добавили еще одно шаблонное правило:
Message
Это правило определяет обработку корневого узла — в атрибуте
match
указан паттерн "/"
, что соответствует корню документа. Шаблон создает элементы html
, head
, title
, body
и в последний включает результат применения шаблонов к элементу msg
. Сравнивая тело этого шаблона с результатом выполнения преобразования, можно заметить, что процессор скопировал все элементы, не принадлежащие XSLT, не изменяя их, а элемент xsl:apply-templates
выполнил, применив шаблон к элементу msg
и включив в body
результат (он выделен в листинге полужирным шрифтом).Продемонстрированная возможность вызова одних правил из других, а также наличие в XSLT таких управляющих конструкций, как
xsl:if
, xsl:choose
и xsl:for-each
позволяет простым набором правил реализовывать очень сложную логику преобразования. В XSLT применяется один из основных принципов эффективной разработки: для того чтобы решить задачу, нужно разбить ее на более мелкие части и решить каждую из них по отдельности. Проблемой в данном случае является преобразование, и вместо того, чтобы описывать его целиком, XSLT позволяет определить простые правила обработки каждой из частей, связав эти правила логикой взаимных вызовов и управляющих конструкций.Отсутствие "побочных" эффектов
Одним из краеугольных принципов XSLT, с которым, увы, нелегко смириться разработчику, работавшему только с процедурными языками, — это отсутствие "побочных" эффектов. Под побочными эффектами в данном случае понимаются изменения в окружении преобразования, которые отражаются на дальнейшем его выполнении.
Концепция отсутствия побочных эффектов берет начало в функциональном программировании, а оно, в свою очередь, в "чистых" математических функциях, не изменяющих своего окружения в процессе вычисления. Например, функция
f(x, у) >вернуть x + у;
будет чистой функцией. Сколько бы раз мы ее не вызывали, ее результат все равно будет равен сумме аргументов. Кроме того, результат вычисления f(f(x1, y1), f(x2, y2)) будет равен x1 + y1 + x2 + y2, в каком бы порядке мы не вычисляли эти функции:
f(f(x1, y1), f(x2, y2)) = f(x1 + y1, f(x2, y2)) = x1 + y1 + f(x2, y2) = x1 + y1 + x2 + y2
f(f(x1, y1), f(x2, y2)) = f(f(x1, y1), x2 + y2) = f(x1, y1) + x2 + y2 = x1 + y1 + x2 + y2
f(f(x1, y1), f(x2, y2)) = f(x1, y1) + f(x2, y2) = x1 + y1 + f(x2, y2) = x1 + y1 + x2 + y2
и так далее.
Представим теперь похожую функцию, обладающую побочным эффектом:
f(x, у) →z присвоить x; увеличить z на у; вернуть z;
В данном случае побочный эффект состоит в изменении значения переменной z. В этом случае результат вычисления выражения f(z, f(x, у)) строго зависит от того, в каком порядке будут вычисляться функции — в одних случаях результатом будет x + у + z, в других 2∙x + 2∙у. Для того чтобы результат вычислений с побочными эффектами был детерминирован, требуется строгая определенность в порядке действий. В XSLT же эта строгая определенность отсутствует, преобразование — это набор правил, а не последовательность действий.
Таковы теоретические посылки отсутствия побочных эффектов. Главным практическим ограничением является то, что преобразования не могут во время выполнения изменять переменные — после того, как переменной присвоено некоторое начальное значение, измениться оно больше не может.
Сильнее всего это ограничение сказывается на стиле XSLT-программирования. Он становится ближе к функциональному стилю таких языков, как Lisp и Prolog. Научиться соответствовать этому стилю просто, хотя поначалу он и будет казаться неудобным.
Расширения
Слово extensible (англ. расширяемый) в расшифровке аббревиатуры XSLT исторически происходит из названия языка XSL, но оно вполне применимо и к самому XSLT: спецификация этого языка позволяет разрабатывать собственные функции и элементы и использовать их в преобразованиях.
Применительно к преобразованиям структуры, XSLT является чрезвычайно мощным языком, но в то же время вычислительная его часть страдает. В языке XPath, на который переложена задача вычислений в XSLT, есть основные арифметические и логические операторы, небольшая базовая библиотека функций для работы с различными типами данных — но не более. XPath мало подходит для действительно сложных вычислительных задач. Что касается самого XSLT, набор элементов этого языка можно назвать вполне достаточным для большинства задач. Но и тут встречаются приложения (и разработчики), которые требуют большего.
Следуя спецификации, большинство реализаций XSLT предоставляет интерфейсы для разработки собственных функций, немного реже — элементов. Расширения пишутся на обычных языках программирования, таких как Java или С, но используются в XSLT так же, как использовались бы обычные функции и элементы.
Технология расширений делает XSLT поистине универсальным языком, ведь получается, что в нем можно использовать любые вычисления, которые только могут быть описаны в классических языках программирования.
К сожалению, вследствие различий в интерфейсах расширений, их использования приводит к потере переносимости между платформами и процессорами. Если преобразования, созданные в соответствии со стандартом языка, будут, как правило, без проблем выполняться различными процессорами, использование расширений в большинстве случаев ограничивает переносимость преобразования.
Преобразования снаружи