Различные требования
Как мы уже видели, XSLT появился в результате работы над XSL (eXtensible Stylesheet Language – расширяемый язык стилей), чьей главной целью было представление (для восприятия человеком) информации, содержавшейся в XML документах. Хотя концепция преобразования имеет намного более широкое применение, и язык был разработан пригодным для выполнения широкого круга задач преобразования, моделирование XML осталось основным вариантом использования. Тот факт, что рабочая группа хотела сконцентрироваться на этом требовании, очевиден из утверждения в самом начале спецификации XSLT 1.0: «XSLT не разрабатывался в качестве многоцелевого языка преобразований. Напротив, он предназначен прежде всего для тех видов преобразований, которые требуются в том случае, когда XSLT используется как часть XSL» [XSLT, p. 1].
Я не был членом рабочей группы в то время, но я легко представил ее членов, договаривающихся об этом утверждении как о вопросе политики группы, и затем использующие его, чтобы отклонить включение в проект функциональных возможностей, которые считались находящимися вне этой сферы; например, включение расширенных математических операторов или операторов обработки текста. Но также легко вообразить, что некоторые члены группы в душе знали, что был необходим язык преобразований общего назначения, и были уверены, что XSLT должен быть способен выполнить эту задачу. Действительно, если не было людей, веривших в это, то трудно понять, почему было включено утверждение о политике языка, воспроизведенное выше.
Концепция языка преобразований подразумевает некоторые предположения относительно среды обработки. Преобразование по сути принимает один (или несколько) документ на входе и выдает один (или несколько) документ на выходе. Хотя документы обрабатываются в виде деревьев, обычно они поступают для анализа непосредственно из файлов прямо перед началом их преобразования. Документы не загружаются предварительно в базы данных, обеспечивающие специализированную индексацию или методы доступа. Исходный документ не модифицируется процессом преобразования, и он обычно помещается в основную память3.
Тот факт, что рабочая группа сосредоточила усилия на преобразованиях, встречающихся во время моделирования документа, послужил причиной дальнейших предположений. Документо-ориентированный XML встречается чаще, чем информационно-ориентированный XML. Исходные документы могут быть, а могут не быть корректными согласно DTD. Таблицы стилей в основном писались бы для обработки разнообразных исходных документов с различной структурой. Обработка была бы чаще всего последовательной по своей природе: порядок элементов в дереве результата обычно был бы таким же, как и порядок соответствующих элементов в исходном документе. Язык должен, вероятно, быть не очень строгим при обработке ошибок: ошибки в таблице стилей должны позволить получить в результате как можно более полное отображение исходного документа вместо того, чтобы вызвать сообщение об ошибке во время выполнения, которое не означало бы ничего для конечного пользователя.
Предназначенная для языка роль также создала представление об ожидаемом пользователе, который стал бы писать преобразования. Этот пользователь, вероятно, самостоятельно разрабатывал бы как XML документы, так и шаблоны стилей с использованием общих инструментов редактирования XML, вследствие чего также была бы удобной возможность копирования и вставки частей кода XML в таблицы стилей. Эти таблицы обычно создавались бы как компилируемые по требованию автономные документы, доступные с помощью URL; иногда они могли бы быть вложены непосредственно в исходные документы.
Сценарий использования XQuery сильно отличался от приведенного выше. Как язык запросов баз данных, XQuery был предназначен для извлечения информации из больших собраний документов (или больших отдельных документов), которые обычно будут храниться на диске в базах данных с физическими структурами хранения, такими как индексы. Эти индексы позволяют пользователю осуществлять быстрое получение данных. Такие собрания документов часто могли создаваться централизованно, иметь однородную схему и ратифицироваться с помощью этой схемы перед загрузкой в базу данных. Действительно, некоторые разработчики программного обеспечения рассматривают использование XQuery главным образом для запросов представленных в виде XML обычных реляционных баз данных.
Такие различные сценарии использования этих двух языков приводят к раз-личным требованиям или, по крайней мере, к различию в акцентах среди предъявляемых требований. Документы чаще всего бывают информационно-ориентированными, а не документо-ориентированными, хотя язык запросов, как предполагалось, будет способен работать с обоими типами документов. Оптимизация запросов была бы важна для достижения приемлемой производительности, и эта оптимизация включала бы анализ запроса с помощью схемы целевой базы данных только для обнаружения доступных индексов. Поскольку документы часто являются информационно-ориентированными, то сохранение порядка было бы менее важным, а во многих случаях просто ненужным. Обработка ошибок, вероятно, должна быть строгой: если запрос некорректен, то было бы лучше выводить сообщение об ошибке как можно раньше, а не выполнять возможно больший запрос и давать в результате ответ на вопрос, который пользователь и не думал задавать.
Ожидаемый сценарий использования XQuery был бы подобен сценарию использования других языков запросов баз данных, подобных SQL. Иногда опытные пользователи могут использовать язык запросов непосредственно через терминал; но намного чаще запросы вложены в программы, написанные на базовых языках, таких как Java или C#, и возвращают свои результаты переменным базового языка для дальнейшей обработки приложением. Некоторые люди даже рассматривали XQuery в качестве вложенного в SQL подъязыка для поддержки запросов XML в пределах реляционных баз данных. Приведение результатов запроса в последовательную форму в виде XML документа могло бы быть одним из вариантов представления результатов, но ни в коем случае не единственным вариантом. Таким образом, несмотря на значительную схожесть применения языков XSLT и XQuery (они оба выбирают данные из входных XML документов и создают новые XML документы из этих данных), существуют принципиальные различия в основных сценариях использования, которые привели к некоторым главным различиям в заданных параметрах проектов этих языков.
