Трудно оценить технологии, когда у вас нет глубокого опыта их использования, но, конечно, именно тогда вы должны принимать свои решения, поэтому нет простого ответа на эту дилемму.
Вы упоминаете две проблемы: производительность и удобство использования. Я постараюсь обратиться к обоим ниже.
Во-первых, производительность. Производительность, конечно, зависит не только от языка, но и от реализации, а также от опыта пользователей. Разные XSLT-процессоры могут сильно различаться по производительности, и один и тот же процессор может сильно различаться в зависимости от того, как он используется (например, в Saxon люди, у которых есть проблемы с производительностью, очень часто используют его с DOM, что является плохой комбинацией). и производительность может увеличиться в десять раз, если вы вместо этого будете использовать собственную модель дерева Саксона). Поэтому первый совет - не берись за слух, измеряй его; и второй совет - убедиться, что у человека, проводящего измерения, достаточно опыта, чтобы не делать глупых ошибок. Легче сказать, чем сделать.
Грубо говоря, вы можете разделить задания на преобразование на две категории: простые и сложные. Для простых преобразований с хорошим процессором XSLT все время затрачивается на разбор и сериализацию, а время обработки XSLT едва ли уходит на карту. Поскольку любая другая технология будет сопряжена с такими же затратами на синтаксический анализ и сериализацию, выбор технологии преобразования не будет иметь большого значения (за исключением, возможно, очень очень низкого уровня кодирования с использованием потоковой передачи, но не многие люди могут позволить себе программирование время и навыки, необходимые для реализации этого). Для сложных преобразований в больших документах вы начинаете сталкиваться с теми же проблемами, что и при программировании на SQL: для достижения хорошей производительности требуется хорошее взаимодействие между навыками и знаниями программиста и возможностями оптимизатора. Как и в случае с SQL, На таком высокоуровневом языке очень легко написать несколько простых утверждений, которые приводят к тому, что процессору приходится выполнять очень большой объем работы. Но, как и в случае с SQL, программисты, которые знают, что они делают, будут работать намного лучше, чем новички.
Во-вторых, удобство использования. Основанный на XML синтаксис для XSLT очень отталкивает многих людей при первом знакомстве с языком. Но для этого есть веские причины и реальные преимущества: есть аргумент «шаблона», когда большая часть кода состоит из XML, который нужно записать в результирующий документ, и лучший способ написать XML - это XML. И есть аргумент "отражения"; в больших сложных системах очень часто можно найти таблицы стилей, которые генерируют таблицы стилей. Тогда есть аргумент "инструменты"; если вы находитесь в магазине XML, у вас, вероятно, есть много инструментов XML, таких как синтаксически-ориентированные редакторы, и хорошо иметь возможность использовать одни и те же инструменты для обработки ваших программ и ваших данных. Недостатки оказываются довольно косметическими по сравнению: s количество нажатий клавиш, участвующих в редактировании (легко исправляемых с помощью хорошего инструмента редактирования), и многословность кода (снижающая его читабельность). В XSLT 2.0 многословность значительно уменьшена благодаря введению таких функций, как регулярные выражения и функции таблиц стилей: многие таблицы стилей уменьшаются до половины или трети размера, когда они в полной мере используют XSLT 2.0.
Ваше упоминание о DSSSL оставляет меня с кривой улыбкой. Я никогда не использовал DSSSL, но истории, которые я слышал, заключались в том, что он был неудачным, потому что его синтаксис был загадочным и не имел отношения к синтаксису данных (SGML). Использование синтаксиса XML для XSLT было мотивировано опытом работы с DSSSL.
Есть люди, которые любят XSLT, и есть люди, которые ненавидят его. Неудивительно, что те, кто часто его используют, попадают в первую категорию. Те, кому это не нравится, как правило, те, кто не научился «думать по-XSLT». Можно утверждать, что язык программирования не должен влиять на то, как вы думаете, но это так: для написания на языке, основанном на правилах, требуется иной образ мышления, чем для написания на императивном языке. Первой реакцией многих программистов является то, что они чувствуют себя менее контролируемыми (описывают проблему, а не говорят компьютеру, что делать шаг за шагом). Это очень похоже на реакцию, которую вы видели, когда люди впервые познакомились с SQL. В наши дни люди изучают SQL на более ранних этапах своей карьеры, поэтому требуется меньше умственной перестройки.
В конечном счете, вы должны выбрать технологию, основанную на объективных измеримых критериях, а не на реакции любовь / ненависть. Трудно сделать эти измерения. Но многие люди используют XSLT очень интенсивно и очень успешно, поэтому нет никаких сомнений, что это можно сделать.