XSLT и возможные альтернативы [закрыто]


15

Я взглянул на XSLT для преобразования одного XML-файла в другой (HTML и т. Д.). Теперь, когда я вижу преимущества XSLT (являющегося стандартизированным и используемым инструментом), я отказываюсь по нескольким причинам

  • Процессоры XSLT выглядят довольно громадными / ресурсоемкими
  • XML - плохая нотация для программирования, вот в чем суть XSLT.

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

Имея некоторый опыт работы с Lisp, мне интересно, есть ли лучшие способы для преобразования древовидной структуры, основанные на некотором лиспе Я видел ссылки на DSSSL, к сожалению, большинство ссылок о DSSSL мертвы, поэтому уже сложно увидеть некоторый код, который иллюстрирует это. DSSSL все еще используется? Я помню, что однажды я установил openjade при просмотре документации в docbook.

Сообщение в блоге Джеффа Этвуда, похоже, намекает на использование Ruby вместо XSLT.

Есть ли какие-нибудь разумные способы сделать преобразования XML, подобные XSLT, в языке программирования не-xml? Я был бы открыт для ввода на

  • Полезные библиотеки для языков сценариев, которые облегчают преобразования XML
  • особенно (но не исключительно) лисп-подобные языки преобразования или Ruby и т. д.

Несколько вещей, которые я нашел до сих пор:


Я использую HXT и Haskell довольно часто, это очень приятно
Даниэль Гратцер

5
Справедливости ради, это не Джефф Этвуд, который защищает Руби, он цитирует Мартина Фаулера, который предпочитает Руби. Оригинальный пост Фаулера находится здесь: martinfowler.com/bliki/MovingAwayFromXslt.html И он был написан 10 лет назад в 2003 году - я думаю, что XSLT 2.0 вышел в 2007 году и со многими улучшениями, а XPath 2.0 - в 2010 году.
FrustratedWithFormsDesigner

Ответы:


18

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

Вы упоминаете две проблемы: производительность и удобство использования. Я постараюсь обратиться к обоим ниже.

Во-первых, производительность. Производительность, конечно, зависит не только от языка, но и от реализации, а также от опыта пользователей. Разные 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 очень интенсивно и очень успешно, поэтому нет никаких сомнений, что это можно сделать.


2
Более распространенным термином «язык на основе правил» является декларативный язык.
Даниэль Гратцер

@ Майкл Кей - Хорошо. Я лично люблю XSLT и использую его с C #. Кроме того, я использую его с XSL-FO для создания PDF-документов. XSLT - мощный, очень мощный инструмент, позволяющий быстро конвертировать большие объемы данных в HTML, XSL-FO, XML или Text.
PhillyNJ

3

Без дополнительной информации о контексте трудно ответить.

Тем не менее, я не понимаю, почему вы не хотите использовать XSLT. Это правильный инструмент для работы и мощный. Это сделано специально для преобразования одного XML в другой.

Процессоры XSLT выглядят довольно громадными / ресурсоемкими

У вас есть точные данные, чтобы поддержать это? Внедрили ли вы решение с использованием XSLT и обнаружили, что XSLT является узким местом, которое делает невозможным доставку продукта при выполнении всех нефункциональных требований, связанных с производительностью?

Без статистических данных и профилирования вы не сможете обоснованно утверждать, что данное решение не будет работать. Являются ли нефункциональные требования достаточно разумными? Вы бы предпочли потратить, скажем, десять дней работы разработчиков, чтобы получить несколько сотен миллисекунд, заменив XSLT другой альтернативой? Стоит ли это того?

XML - плохая нотация для программирования, вот в чем суть XSLT.

Итак, вы хотите преобразовать один XML в другой, но не хотите использовать XSLT, потому что «XML - плохая нотация»?

Если тот факт, что вы используете XML как своего рода язык программирования, который вас так раздражает, рассматривайте его не как программирование, а как набор правил преобразования.

Вам даже не нужно писать XSLT вручную. Существует множество редакторов ETL, которые позволяют графически отображать один XML в другой: никакого программирования не требуется. Некоторые из них используют XSLT в качестве вывода.


Я столкнулся с проблемами с ресурсами листов на основе XSLT, они были созданы с помощью графического инструмента, но он перестал работать с большими файлами.
wirrbel

1
тогда, вероятно, есть проблемы с вашими XSLT fileне XSLT Transformationsсамими
Малахи

Сейчас я не осуждаю XML, на самом деле я думаю, что он подходит для представления данных (особенно для разметки). Как «язык программирования» - а XSLT является языком программирования, специфичным для предметной области, - это неудобно. <xsl: what> теги, метаязыки (например, xpath, $ notation и т. д.) в атрибутах запроса, все, что не отображается в XML, помещается в кавычки атрибутов. Чтобы получить представление о представлении XML с помощью s-выражений: blog.getprismatic.com/blog/2013/1/22/… в таком месте может казаться, что XML и proglang работают
неоправданно

1

Если вы используете XSLT для генерации XML на основе необработанного XSLT и некоторых параметров, передаваемых в механизм XSLT, то использование подхода XML на основе шаблонов намного проще для понимания и поддержки.

Я был в проекте, где Mustache использовался для замены XSLT, и в результате получилось намного проще базовых XML-файлов, которые каждый мог редактировать и настраивать, чем то, что работа над проектом передавалась одной или двум смельчакам, которые сидели в полной тишине с каплями пота ...

Шаблонный подход не подходит для использования, когда базовый XML также сам по себе является действительными данными, и этот XSLT используется для предоставления альтернативного представления или извлечения из исходного XML.


Вы не могли бы объяснить больше о том, что он делает, и почему вы рекомендуете ответить на заданный вопрос? «Ответы только на ссылки» не очень приветствуются на Stack Exchange
коммент

1
проверенный ответ в соответствии с вашими отзывами
Майкл Шоу,

0

XML не является языком программирования

XML - это способ переноса / переноса данных.
инструкция XSLT использует Xpath для запроса данных определенным образом и помещения его в другой объект / документ транспорта данных.

И / ИЛИ

XSLT может преобразовать ваш XML в HTML, что является еще одним способом отображения / транспортировки данных, содержащихся в документе XML.

если вы хотите изменить XML или создать XML-документ, вы можете использовать любое количество языков: C #, VB, Ruby и т. д.

обычно, когда вы используете XSLT-файл для преобразования XML-документа, у вас все еще есть исходный XML-документ, вы фактически не меняете исходный документ, вы действительно создаете новый.


1
Википедия говорит: «XSLT - полный по Тьюрингу язык, то есть он может определять любые вычисления, которые могут быть выполнены компьютером». Я никогда не говорил, что XML является языком программирования как таковым.
wirrbel

Вы сказали, что «XML - плохая нотация для программирования» на языках программирования, которые я использовал, вы можете легко извлекать данные из файлов XML. XSLT приобретает все большую популярность благодаря возможности выполнять много вычислений и выводить эти данные на другой объект / документ передачи данных. это как SQL для SQL Server, он может делать много вещей, но это в основном бэкэнд, а не фронтэнд. SQL похож на XSLT, он запрашивает данные особым образом, но вы никогда не хотите предоставлять результаты этого запроса в виде отчета, вы хотите отправить информацию в построитель отчетов
Malachi

2
XSLT не запрашивает данные, XPATH выполняет запросы. Разве XSLT не является декларативным языком, который определяет инструкции для разобранного XML?
PhillyNJ

XSLT определяет правила преобразования на основе шаблонов, для которых он может использовать Xpath. Т.е. у вас могут быть высокоуровневые программные конструкции, например xsl:for-each xsl:apply-templates, xsl:if xsl:call-template xsl:value-ofдля определения правил преобразования.
wirrbel

1
@PhilVallone Я согласен. Я был не прав там. wirrbel, я не собираюсь спорить с вами о том, что такое XSLT / XSL, а что нет, если вы хотите преобразовать ваш XML-документ в другой XML-документ, который вы захотите использовать XSLT / XSL.
Малахи

0

Я работал над несколькими системами обработки XML, которые объединяют библиотеки XSLT с Java или C ++ для частей, в которых XSLT не так хорош. Существуют библиотеки, которые получают очень хорошую производительность XSLT даже для XML-файлов размером 20 МБ, однако XSLT имеет некоторые ограничения в отношении контекста, переменных и действительно сложных строковых шаблонов. В каждой системе, над которой я работал, в Java / C ++ было сделано несколько вещей, потому что контекст был важен, или помогало какое-то сложное выражение регулярного выражения. Мой вывод: XSLT плюс некоторый дополнительный код на выбранном вами языке - хороший способ преобразования XML.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.