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

Ответ 1

Одна из проблем заключается в том, что XSLT выглядит сложным. Любой разработчик должен иметь возможность выбирать языковые конструкции, поскольку на большинстве других языков есть аналоги. Проблема в том, что конструкции и данные выглядят совершенно одинаково, что затрудняет различие между ними, что затрудняет чтение XSLT, чем другие languges.

Вторая проблема заключается в том, что ее использование более ограничено, чем другие языки. XSLT отлично справляется с тем, что он делает; делая сложные или радикальные преобразования в XML. Но это не относится к широкому кругу проблем, как и к другим языкам, поэтому он не используется так много.

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

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

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

Ответ 2

XSLT использует функциональное программирование - то, к чему большинство программистов не привыкли (отсюда почему некоторые люди считают это неинтуитивным, я думаю).

Ответ 3

На мой взгляд, одна из самых неприятных вещей в стандартном XSLT (я говорю о XSLT 1.0, потому что единственная версия, которую я использовал) заключается в том, что ей не хватало поддержки строковых преобразований и некоторых базовых манипуляций с функциями даты и времени.

Одна вещь, которую я никогда не мог понять, - это то, почему функция, такая как translate(), была спроектирована и реализована в xpath с другими более полезными функциями, такими как replace, to_lower, to_upper или - пусть будет сумасшедшим - регулярных выражений не было.

Некоторые из этих проблем были адресованы. Я полагаю, что eXSLT (расширенный xslt?) для парсеров, отличных от Microsoft MSXML. Я говорю, я думаю, потому что я на самом деле никогда не использовал его, поскольку он был объявлен несовместимым с MSXML.

Я не понимаю, почему XSLT 1.0 был разработан с этим принципом, что манипуляция "текстом" не была в пределах языка, когда было очевидно, что всякий раз, когда вы конвертируете файлы, вы не можете избежать проблем с преобразованием строк (например,: преобразовать нерегулярно заполненную дату, указанную во французском формате, в американский формат, 31/1/2008 - 2008-01-31) huh...

Эти проблемы с манипулированием текстом, как правило, были очень простыми и легко адресованы в MSXML, позволяя расширить XSL с помощью функций JScript: вы могли бы вызвать функцию JScript для выполнения некоторой обработки так же, как вы могли бы называть любой XSL-шаблон, но я всегда обнаружил, что решение inelegant и в конечном итоге создало собственные библиотеки шаблонов XSL. Во-первых, из-за того, что способ JScript нарушил переносимость XSL, а затем потому, что он заставил вас смешать вашу логику программирования: некоторые биты в чистом выражении XPath/XSLT и другие биты в DOM/объектной нотации с JScript.

Не имея обновляемых переменных, это еще одно ограничение, которое очень сбивает с толку для новичков, некоторые просто не справляются с этим и продолжают бороться с этим. В некоторых простых случаях у вас могут быть обходные пути с сочетанием шаблонов и рекурсивных вызовов (например, для реализации увеличивающего или деградирующего счетчика), но пусть сталкиваются с этим, рекурсия не является естественной.

Думаю, я слышал, что все эти ограничения были указаны в спецификации XSLT 2.0, к сожалению, MS решила не реализовывать ее и вместо этого продвигать XQuery. Что грустно, почему бы не реализовать их обоих? Я думаю, что XSLT по-прежнему будет иметь хорошие шансы стать таким же популярным, как CSS для HTML. Когда вы думаете об этом, самой сложной частью обучения XSLT является XPath, остальное не так сложно, как понимание каскадного поведения в CSS, и CSS стал настолько популярным...

Таким образом, на мой взгляд, это отсутствие всех упомянутых здесь мелочей и время, которое потребовалось, чтобы адресовать их в XSLT 2.0 (при этом даже MS не поддерживала его), что привело к этой ситуации impopularity. Как я хочу, MS решила реализовать его в конце концов...

Ответ 4

Поскольку большинство реализаций XSLT имеют большой объем памяти (я полагаю, что это вызвано дизайном языка), потому что люди склонны злоупотреблять XSLT для всех видов вещей, для которых он не был особенно хорошо подходит и чисто декларативный характер XSL, что затрудняет определенные типы преобразований.

Ответ 5

Это отлично подходит для xml, но не подходит для типичного кодирования. Ему не хватает типичных базовых понятий (т.е. Изменяемых переменных) и делает то, что должно быть простым довольно сложным (или невозможным). Большинство его проблем связано с тем, что xml - отличный язык представления данных, но не отличный язык программирования. При этом я использую его ежедневно и рекомендую его там, где это имеет смысл. В сочетании с внешними пространствами имен он может быть полезен (вызовы java и т.д.). В конце концов, это другой язык для изучения, и многие кодеры предпочитают придерживаться того, к чему они привыкли или похожи на то, к чему они привыкли.

Ответ 6

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

Ответ 7

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

<Really> 
    <No>
        <fun/>
    </No>
</Really>         

(Я знаю, что это не xslt)

Ответ 8

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

Ответ 9

Потому что проще писать и поддерживать код, который использует Java, С#, JavaScript и т.д., чтобы десериализовать поток XML, преобразовать его и экспортировать желаемый результат, а XSLT не имеет существенного преимущества в производительности.

XSLT делает что-то легким, но делает другие вещи очень и очень тяжелыми.

Ответ 10

Я думаю, что это сводится к синтаксису XML, возможно, полезно для описания данных, но это не отличный синтаксис для того, что по существу является языком программирования (XSLT).

Ответ 11

Как уже было сказано, XSLT (например, "хорошие части" JavaScript) является языком функционального программирования. Большинство традиционных программистов ненавидят эту безгражданство. Также слишком много традиционных программистов ненавидят угловые скобки.

Но самое главное, правильное использование XSLT решает как декларативно-GUI-генерация, так и проблему привязки данных для веб-сервера в агностическом режиме платформы. Поставщики, подобные Microsoft, не мотивированы, чтобы отпраздновать эту "неудобную" власть.

Однако я буду утверждать, что Microsoft имеет самую лучшую поддержку XSLT для IDE (Visual Studio) в мире.

Ответ 12

Я думаю, что он пытался охватить слишком много случаев использования, став, таким образом, языком Turing-complete (или так я слышал). Если вы попытаетесь сделать какое-либо нетривиальное преобразование, вы закончите писать сложные циклы, условия... на уродливом и подробном языке, который лучше всего делать с помощью GPL.

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

Ответ 13

XSLT очень мощный, но требует другого способа мышления о проблеме. Это также сделало жизнь тяжелой для себя, не предоставляя полезных функций данных в ранних версиях. Возьмем, например, метод стиля ToUpper(), вы обычно реализуете его с помощью чего-то вроде:

<xsl:variable name="lcletters">abcdefghijklmnopqrstuvwxyz</xsl:variable>
<xsl:variable name="ucletters">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable>  

<xsl:value-of select="translate($toconvert,$lcletters,$ucletters)"/>

Не самый простой способ кодирования!

Ответ 14

xslt отлично подходит для xml-xml, когда у вас есть данные, которые уже экранированы, и четкое определение входов и выходов. использование его для таких вещей, как xml2html, мне просто кажется такой головной болью, и почти с любым динамическим языком и css вывод намного проще реализовать со стилем.

Ответ 15

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