В чем смысл фрагмента дерева результатов?

Question

XSLT 1.0 добавляет дополнительный тип данных к предоставляемым XPath 1.0: фрагменты дерева результатов.

Этот дополнительный тип данных называется фрагментом дерева результатов. Переменная может быть связана с фрагментом результирующего дерева вместо одного из четырех основных типов данных XPath (строка, число, логическое значение, набор узлов). Фрагмент результирующего дерева представляет собой фрагмент результирующего дерева. Фрагмент дерева результатов обрабатывается эквивалентно набору узлов, который содержит только один корневой узел. Однако операции, разрешенные для фрагмента дерева результатов, являются подмножеством операций, разрешенных для набора узлов. Операция разрешена для фрагмента результирующего дерева, только если эта операция будет разрешена для строки (операция со строкой может включать в себя сначала преобразование строки в число или логическое значение). В частности, запрещено использовать /, //, а также [] операторы на фрагментах дерева результатов.
- https://www.w3.org/TR/xslt-10/

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

Чтобы еще больше использовать бесполезность фрагментов дерева результатов, вот пример совместимости I украл собрать вместе, чтобы воспроизвести exsl:node-set в MSXSL:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:exsl="http://exslt.org/common"
                xmlns:msxsl="urn:schemas-microsoft-com:xslt"
                exclude-result-prefixes="exsl msxsl">
  <!-- exsl:node-set -->
  <msxsl:script language="JScript" implements-prefix="exsl"><![CDATA[
    this['node-set'] = function (x) {
      return x;
    }
  ]]></msxsl:script>
</xsl:stylesheet>

Это буквально просто возвращает фрагмент результирующего дерева без изменений, предполагая, что MSXSL даже не заботится о реализации фрагмента результирующего дерева как другого типа, а просто обрабатывает его идентично node-setДалее, предполагая, что в этом нет особого смысла!

Почему существуют фрагменты дерева результатов?

• Какой вариант использования?
• Почему они были добавлены?
• Почему бы просто не использовать набор узлов?

Answer 1

Я не был в Рабочей группе в то время, но следующий обмен мог бы пролить некоторый свет. В апреле 2001 года во время разработки XSLT 1.1 я спросил WG:

Может ли кто-нибудь попытаться объяснить мне, почему существует явная проблема со средством "фрагмент дерева результатов как набор узлов", как это определено в XSLT 1.1 WD? Я продолжаю слышать, что это не будет работать с системой типов XPath 2.0, но я не понимаю, почему.

Я вижу, что мы хотим изменить его так, чтобы тип данных был "узел", а не "набор узлов", но кроме этого, я не вижу, в чем проблема.

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

Джеймс Кларк ответил:

Возможно ли, что кто-то задумал покончить с корневым узлом временного дерева и сделать вместо него значение переменной последовательностью узлов, которые в настоящее время моделируются как дочерние элементы этого корня?

Да.

Если так, то почему это изменение будет полезным?

(а) Таким образом, инструкции могут возвращать узлы, не копируя их.

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

Более подробное объяснение потребовало бы от меня объяснения, каким образом я надеюсь, что XPath, XSLT и XQuery все будут совмещаться. На данный момент, позвольте мне просто сказать, что я думаю, что нам нужно согласовать конструирование элементов в XSLT и XQuery. Это, естественно, приведет к тому, что между выражениями и инструкциями будет намного меньше пропасти. Я думаю, что для xsl:variable будет так же неловко и неуместно автоматически копировать и переносить в корневой узел значение, созданное путем создания экземпляра его содержимого, как если бы он делал это со значением, полученным путем вычисления выражения указано в атрибуте выбора.

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

Оглядываясь назад, я убежден, что это была ошибка, потому что она не достигла этой цели. Когда мы отменили RTF в версии 2.0, мы все же сочли необходимым по причинам обратной совместимости иметь причудливое правило, которое xsl:variable всегда создает узел документа, если отсутствует атрибут "как".

Стоит отметить, что никто в РГ никогда не предполагал, что люди все еще будут использовать XSLT 1.0 двадцать лет спустя. На разработку версии 1.0 ушло около двух лет, и WG полностью ожидала, что в течение двух лет она будет полностью заменена более поздней версией. Поэтому они были очень готовы наложить ограничения на язык, если они оставляли открытыми опции для следующей версии.