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

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

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

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

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

Не самый легкий способ кодировать!

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

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

Поскольку ранее указанная XSLT (как “the хороший parts” JavaScript) является языком функционального программирования. Самые традиционные программисты ненавидят это отсутствие гражданства. Также слишком много традиционных программистов ненавидят угловые скобки.

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

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

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

XSL является господствующей тенденцией и широко принятый. К чему другие языки - Вы относящийся? XSL не является языком программирования, просто язык преобразования , таким образом, он довольно ограничен в объеме.

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

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

(я действительно знаю, что это не xslt)

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

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

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

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

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

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

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

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

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

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

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

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

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

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