Важко оцінити технології, коли ти не маєш глибокого досвіду їх використання, але, звичайно, саме тоді ти повинен приймати свої рішення, тому на цю дилему немає простої відповіді.
Ви цитуєте дві проблеми: продуктивність та зручність використання. Я спробую звернутися до обох нижче.
По-перше, продуктивність. Продуктивність, звичайно, залежить не тільки від мови, але й від реалізації, а також від досвідченості користувачів. Різні процесори XSLT можуть сильно відрізнятися по продуктивності, і той самий процесор може сильно відрізнятися залежно від способу його використання (наприклад, Saxon, наприклад, люди, які мають проблеми з продуктивністю, дуже часто виявляються, що використовують його разом з DOM, що є поганою комбінацією , а продуктивність може збільшитися в десятки разів, якщо ви замість цього використовуєте вроджену модель дерева Saxon). Тож перша порада - не сприймайте чужі результати, заміряйте це; а друга порада - переконатися, що людина, яка проводить вимірювання, має достатньо досвіду, щоб не робити дурних помилок. Легше сказати, ніж зробити.
Грубо ви можете розділити завдання перетворення на дві категорії: прості та складні. Для простого перетворення, при хорошому XSLT-процесорі час витрачається на розбір і серіалізацію, і час обробки XSLT навряд чи потрапляє у зображення. Оскільки будь-яка інша технологія понесе ті самі витрати на розбір та серіалізацію, вибір технології перетворення не призведе до великої різниці (за винятком, можливо, кодування дуже низького рівня з використанням потокової передачі, але не багато людей можуть дозволити собі програмування час та навички, необхідні для цього). Для складних перетворень на великих документах ви починаєте отримувати ті самі проблеми, що і для програмування SQL: для досягнення хорошої продуктивності потрібна хороша взаємодія між навичками та знаннями програміста та можливостями оптимізатора. Як і у SQL, це ' З такою мовою високого рівня дуже просто написати кілька простих заяв, в результаті яких процесору доведеться виконати дуже велику кількість роботи. Але також як і у SQL, програмісти, які знають, що вони роблять, будуть робити набагато краще, ніж новачки.
По-друге, зручність використання. Синтаксис XSLT на основі XML дуже невдалий для першої зустрічі з мовою. Але є вагомі причини та реальні переваги для цього таким чином: є аргумент "шаблон", що багато коду складається з XML, який потрібно записати в результатний документ, а найкращий спосіб записати XML - це у XML. І є аргумент "рефлексія"; у великих складних системах дуже часто зустрічаються таблиці стилів, які генерують таблиці стилів. Тоді є аргумент "інструменти"; якщо ви перебуваєте в магазині XML, у вас, ймовірно, є багато інструментів XML, таких як редактори, спрямовані на синтаксис, і це добре, щоб мати можливість використовувати ті самі інструменти для обробки ваших програм та ваших даних. Недоліки виявляються досить косметичними порівняно: s кількість натискань клавіш, що беруть участь у редагуванні (легко виправляється за допомогою хорошого інструмента редагування), і є багатослівність коду (зменшення його читабельності). Багатослівність значно зменшується в XSLT 2.0 завдяки впровадженню таких функцій, як регулярні вирази та функції таблиць стилів: багато таблиць стилів зменшуються до половини або третини за розміром, коли вони повністю використовують перевагу XSLT 2.0.
Ваша згадка про DSSSL залишає мене з кривою посмішкою. Я ніколи не використовував DSSSL, але розповіді, які я чув, що це було непотрібно, оскільки його синтаксис був прихованим та не пов'язаним із синтаксисом даних (SGML). Використання синтаксису XML для XSLT було сильно мотивоване досвідом роботи з DSSSL.
Є люди, які люблять XSLT, і є люди, які ненавидять його. Не дивно, що ті, хто її багато використовує, як правило, потрапляють до першої категорії. Ті, хто це не любить, - це, як правило, ті, хто не навчився "думати XSLT". Ви можете стверджувати, що мова програмування не повинна впливати на те, як ви думаєте, але це робить: писання мовою, заснованою на правилах, вимагає іншого мислення, ніж письмово необхідною мовою. Перша реакція багатьох програмістів полягає в тому, що вони менше контролюють (описують проблему, а не кажуть комп'ютеру, що робити крок за кроком). Це дуже схоже на реакцію, яку ви бачили, коли люди вперше знайомилися з SQL. У наші дні люди вивчають SQL раніше у своїй кар’єрі, тому не потрібно меншої перебудови розумової діяльності.
Зрештою, ви повинні вибрати технологію, засновану на об'єктивних вимірюваних критеріях, а не на реакціях любові / ненависті. Зробити ці вимірювання важко. Але є багато людей, які використовують XSLT дуже інтенсивно і дуже успішно, тому немає сумнівів, що це можна зробити.