Я столкнулся с некоторой своеобразной разницей в поведении процессоров XSLT. Интересно, что является причиной этого и есть ли полный обзор доступных отличий процессоров.
Я проверил следующее простое преобразование (с фиктивным вводом):
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:output method="text"/>
<xsl:template match="/">
<xsl:text>1=
2=
3=
4=

end</xsl:text>
</xsl:template>
</xsl:stylesheet>
Запускать в XML Spy (v 2011 sp1 x64), вывод:
1=
2=
3=
4=
end
Во всех случаях в шестнадцатеричном формате после =
и в строке после 4=
были добавлены два символа 0D
и 0A
.
Очевидно, что XML Spy заменяет каждый запрос на &xA;
или &xD;
полным вхождением CR + LF, за исключением случаев, когда CR и LF запрашиваются в этом порядке, сразу после друг друга (см. Часть 3 =).
Но при запуске в saxon9he я получаю предупреждение о том, что я запускаю таблицу стилей v1.0 с процессором v2.0, и вывод
1=
2=3=
4=
end
В этом случае все запросы на &xA;
заменяются на 0D 0A
(таким образом, CR добавляется перед LF), но запрос на &xD;
выводит запрошенный CR, а не дополнительный LF.
При повторном запуске в XML Spy установка XSLT-версии на 2.0 дает тот же результат, что и для 1.0, так что я полагаю, что в двух версиях XSLT это не другое соглашение.
Скорее всего, это просто различие между инструментами, о которых мы должны знать, но мне интересно, есть ли что сказать по этому вопросу.