История изменений
Исправление annulen, (текущая версия) :
Понятно что сразу на ум приходит технология с названием XSLT
Сразу оговорюсь, с XSLT я не работал серьёзно никогда
Тогда выбор неочевидный и даже сомнительный.
Если суть проекта в преобразовании XML в HTML, то тогда основным инструментом разработки станет именно XSLT, а не «хостовый» язык или фреймворк, которые ты пытаешься выбрать. Мне лично XSLT показался неприятным в использовании. В нём есть внутри полезная штука — XPath, но XPath поддерживается очень много где ещё.
Вместо XSLT можно использовать XQuery. Там тоже внутри XPath, и язык, на мой взгляд, более адекватный. Но всё равно можно столкнуться с ситуацией, когда приходится ломать голову, как сделать то, что хочется, и это происходит не из-за сложности задачи или из-за того, что язык пытается уберечь от ошибок, а просто из-за его кривизны. Плюс реализаций XQuery сильно меньше, чем XSLT.
Поэтому я бы на твоём месте рассмотрел вариант использовать ЯП общего назначения с DOM-парсером, и генерить HTML императивным кодом. Лучше, если парсер умеет XPath или какие-то другие плюшки для упрощения выборок из дерева. Например, для python есть pyquery.
Единственное, в чём может быть реальный профит от XSLT — это если надо перемалывать мегатонны разных XML в секунду без возможности сэкономить за счёт кэширования. Тогда выполнение XSLT через нативные библиотеки libxml2 и libxslt может сильно сэкономить затрачиваемые ресурсы по сравнению со скриптухой (а может даже и с шарпами, но тут я не силён).
rust … идут лесом, они не для такой задачи
FWIW, я знаю людей, которые на серьёзных щах на расте пишут круды, генерилки кода и подобную фигню, которую раньше принято было на скриптухе писать. Так что не стоит его с асмом в один ряд ставить.
Исходная версия annulen, :
Понятно что сразу на ум приходит технология с названием XSLT
Сразу оговорюсь, с XSLT я не работал серьёзно никогда
Тогда выбор неочевидный и даже сомнительный.
Если суть проекта в преобразовании XML в HTML, то тогда основным языком разработки станет XSLT. Мне лично он показался неприятным в использовании. В нём есть внутри полезная штука — XPath, но XPath поддерживается очень много где ещё.
Вместо XSLT можно использовать XQuery. Там тоже внутри XPath, и язык, на мой взгляд, более адекватный. Но всё равно можно столкнуться с ситуацией, когда приходится ломать голову, как сделать то, что хочется, и это происходит не из-за сложности задачи или из-за того, что язык пытается уберечь от ошибок, а просто из-за его кривизны. Плюс реализаций XQuery сильно меньше, чем XSLT.
Поэтому я бы на твоём месте рассмотрел вариант использовать ЯП общего назначения с DOM-парсером, и генерить HTML императивным кодом. Лучше, если парсер умеет XPath или какие-то другие плюшки для упрощения выборок из дерева. Например, для python есть pyquery.
Единственное, в чём может быть реальный профит от XSLT — это если надо перемалывать мегатонны разных XML в секунду без возможности сэкономить за счёт кэширования. Тогда выполнение XSLT через нативные библиотеки libxml2 и libxslt может сильно сэкономить затрачиваемые ресурсы по сравнению со скриптухой (а может даже и с шарпами, но тут я не силён).
rust … идут лесом, они не для такой задачи
FWIW, я знаю людей, которые на серьёзных щах на расте пишут круды, генерилки кода и подобную фигню, которую раньше принято было на скриптухе писать. Так что не стоит его с асмом в один ряд ставить.