Почему XSLT никогда не пользовался такой популярностью, как многие другие языки, появившиеся во время интернет-бума?[закрыто]
https://stackoverflow.com/questions/77342
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Использование XSLT (преобразование языка таблиц стилей XML) никогда не было таким популярным, как многие другие языки, появившиеся во время интернет-бума.Пока он используется, а в некоторых случаях крупными успешными компаниями (т.е.Blizzard Entertainment), казалось, что она так и не стала мейнстримом.Как ты думаешь, почему это так?
Решение
Одна из проблем заключается в том, что XSLT выглядит сложный.Любой разработчик должен уметь подбирать языковые конструкции, поскольку аналоги есть в большинстве других языков.Проблема в том, что все конструкции и данные выглядят абсолютно одинаково, что затрудняет различие между ними, что делает XSLT более сложным для чтения, чем другие языки.
Вторая проблема заключается в том, что его использование более ограничено, чем в других языках.XSLT великолепен в том, что он делает;выполнение сложных или радикальных преобразований в XML.Но он не применим к столь широкому кругу проблем, как другие языки, поэтому используется не так часто.
В-третьих, многие языки программирования имеют свои собственные библиотеки для преобразования XML.Большую часть времени при работе с XML требуются лишь небольшие изменения или поисковые запросы.XML также, вероятно, генерируется или используется программой, которую разработчик уже пишет на другом языке.Эти факторы означают, что использование встроенных в язык утилит просто удобнее.
Еще одна проблема, которой способствуют все эти проблемы, - это инерция.То есть люди этого не знают, они не видят, что им это очень нужно, поэтому они избегают этого как решения, если есть другой вариант.
В итоге вы получаете язык, который многие разработчики выбирают в последнюю очередь при создании решений.Вполне вероятно, что XSLT даже избегают, когда в результате это был бы лучший инструмент для выполнения задачи.
Другие советы
XSLTs использует функциональное программирование - то, к чему большинство программистов не привыкли (я думаю, поэтому некоторые люди считают это неинтуитивным).
На мой взгляд, одна из самых раздражающих вещей в стандартном XSLT (я говорю о XSLT 1.0, потому что это единственная версия, которую я использовал) заключается в том, что в нем отсутствовала поддержка преобразований строк и некоторых базовых манипуляций с функциями даты и времени.
Одна вещь, которую я никогда не мог понять, - это почему такая функция, как translate(), была разработана и реализована в xpath, тогда как другие, более полезные функции, такие как заменить, to_lower, to_upper ( то_уппер ), или - давайте будем сумасшедшими - регулярных выражений не было.
Некоторые из этих проблем, я полагаю, были решены с помощью eXSLT (расширенный xslt ?) для анализаторов, отличных от MSXML от Microsoft.Я говорю "наверное", потому что на самом деле я никогда не использовал его, поскольку он был объявлен несовместимым с MSXML.
Я не понимаю, почему XSLT 1.0 был разработан с учетом этого принципа, согласно которому манипулирование "текстом" не входило в сферу применения языка, когда очевидно, что всякий раз, когда вы конвертируете файлы, вы не можете избежать этих проблем с преобразованием строк (например:преобразуйте нерегулярно дополненную дату, указанную во французском формате, в американский формат, 31/1/2008 в 2008-01-31) ага...
Эти проблемы с манипулированием текстом, как правило, были очень простыми и легко решались в MSXML, позволяя расширять XSL функциями JScript :вы могли бы вызвать функцию JScript для выполнения некоторой обработки точно так же, как вы бы вызвали любой шаблон XSL, но я всегда находил это решение неэлегантным и в итоге создал свои собственные библиотеки шаблонов XSL.Сначала потому, что способ JScript нарушил вашу переносимость XSL, а затем потому, что это вынудило вас смешивать вашу логику программирования :некоторые биты в чистом выражении XPath / XSLT, а другие биты в нотации DOM / object с помощью JScript.
Отсутствие обновляемых переменных - это еще одно ограничение, которое очень сбивает с толку новичков, некоторые люди просто не преодолевают это и продолжают бороться с этим.В некоторых простых случаях у вас могут быть обходные пути с сочетанием параметризованных шаблонов и рекурсивных вызовов (например, для реализации увеличения или уменьшения количества счетчиков), но давайте посмотрим правде в глаза, рекурсия не настолько естественна.
Я думаю, я слышал, что все эти ограничения были учтены в спецификации XSLT 2.0, к сожалению, MS решила не внедрять ее и вместо этого продвигать XQuery.Это печально, почему бы не реализовать их оба?Я думаю, что у XSLT все еще были бы хорошие шансы стать таким же популярным, каким CSS стал для HTML.Если подумать, то самая сложная часть в изучении XSLT - это XPath, остальное не так сложно, как понимание каскадного поведения в CSS, а CSS стал таким популярным...
Итак, на мой взгляд, именно отсутствие всех этих мелочей, упомянутых здесь, и время, затраченное на их обработку в XSLT 2.0 (в любом случае, даже MS его не поддерживает), привело к такой ситуации непопулярности.Как бы я хотел, чтобы MS все-таки решила это реализовать...
Потому что большинство реализаций XSLT имеют большой объем памяти (я полагаю, это вызвано дизайном языка), потому что люди склонны злоупотреблять XSLT для всех видов вещей, для которых он не особенно хорошо подходит, и чисто декларативный характер XSL, который делает определенные типы преобразований довольно сложными.
Он отлично подходит для xml, но не подходит для обычного кодирования.В нем отсутствуют типичные базовые понятия (т. Е. изменяемые переменные) и делает то, что должно быть простым, довольно сложным (или невозможным).Большинство его проблем проистекают из того факта, что xml - отличный язык представления данных, но не лучший язык программирования.Тем не менее, я использую его ежедневно и рекомендовал бы там, где это имеет смысл.В сочетании с внешними пространствами имен это можно сделать более полезным (вызовы java и т.д.).В конце концов, это еще один язык для изучения, и многие программисты предпочли бы придерживаться того, к чему они привыкли, или того, что напоминает то, к чему они привыкли.
Потому что проще писать и поддерживать код, использующий Java, C #, JavaScript и т.д.чтобы десериализовать XML-поток, преобразовать его и экспортировать желаемый результат, XSLT не дает существенного преимущества в производительности.
XSLT делает что-то легким, но это делает другие вещи очень, очень сложными.
Что ж...Может быть, потому, что писать xslts - это мука...Несколько месяцев назад мне пришлось написать несколько xslt, и я мечтал о заостренных скобках...
<Really>
<No>
<fun/>
</No>
</Really>
(Я точно знаю, что это не xslt)
Как правило, случаи, когда вам потребуется преобразовать XML-данные в другую форму XML-данных, но не выполнять с ними никакой другой обработки, будут очень ограничены.Обычно XML используется в качестве посредника между двумя отдельными системами, одна из которых обычно создается на заказ для обработки выходных данных другой.Таким образом, проще просто написать одну из систем для обработки XML-вывода другой без дополнительного шага выполнения какого-либо преобразования.
XSL является мейнстримом и широко распространен.Какие еще языки вы имеете в виду?XSL - это не язык программирования, просто язык преобразования, так что сфера его применения довольно ограничена.
Я думаю, что это сводится к тому, что синтаксис XML, возможно, хорош для описания данных, но это не самый лучший синтаксис для того, что по сути является языком программирования (XSLT).
Как указывалось ранее, XSLT (как и “хорошие части” JavaScript) является функциональным языком программирования.Большинство традиционных программистов ненавидят это безгражданство.Кроме того, слишком многие традиционные программисты ненавидят угловые скобки.
Но, что наиболее важно, правильное использование XSLT решает как проблему генерации декларативного графического интерфейса, так и проблему привязки данных для веб-сервера независимо от платформы.У таких поставщиков, как Microsoft, нет мотивации праздновать эту "неудобную” силу.
Однако я буду утверждать, что Microsoft обладает лучшей поддержкой XSLT для IDE (Visual Studio) во всем мире.
Я думаю, что он пытался охватить слишком много вариантов использования, таким образом став языком, полным по Тьюрингу (по крайней мере, я так слышал).Если вы попытаетесь выполнить какое-либо нетривиальное преобразование, вы в конечном итоге напишете сложные циклы, условия...на уродливом и многословном языке, который лучше всего использовать с помощью GPL.
На мой взгляд, эта сложность затрудняет написание правильной реализации XSLT и ограничивает доступные варианты, что приводит к широкому использованию среди вокальных хакеров, которым часто нравится возиться с небольшим и эффективным кодом, а не с корпоративным кодом.
XSLT очень мощный, но требует другого подхода к проблеме.Это также усложняло жизнь самому себе, не предоставляя полезных функций обработки данных в ранних версиях.Возьмем, к примеру, метод в стиле ToUpper (), обычно вы реализуете его с помощью чего-то вроде:
<xsl:variable name="lcletters">abcdefghijklmnopqrstuvwxyz</xsl:variable>
<xsl:variable name="ucletters">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable>
<xsl:value-of select="translate($toconvert,$lcletters,$ucletters)"/>
Не самый простой способ кодирования!
xslt отлично подходит для преобразования xml в xml, когда у вас есть уже экранированные данные и четкое определение входных и выходных данных.использование его для таких вещей, как xml2html, мне просто кажется такой головной болью, и практически с любым динамическим языком и css вывод намного проще реализовать с помощью style.
Я нашел это отличным для "архитектуры составного веб-сервиса".Иногда несколько веб-сервисов работают вместе, чтобы получить конечный результат.Когда этим веб-сервисам необходимо обмениваться данными между собой через XML, XSLT может преобразовать XML-сообщение из одной формы в другую.
