Я же говорил, что с декларативное программирование — дама вредная. Вы мыслите в категориях совершенно другой парадигмы.
Да ладно, все это не так важно.
Вы меня, конечно, простите, но ваши ужасные xsl:for-each прозрачно намекают на то, что для Вас многие вопросы декларативного программирования покажутся непростыми.
Поддерживаю. Только, к огромному сожалению, Saxon требует приобретения лицензии для возможности использования функций-расширений (как от вендора, так и собственных).
Как только / если в PHP появится стандартный модуль для работы с XSLT/XPath 2.0, он сразу же будет встроен в Easyweb.
Очень вряд ли: на данный момент мне известен только один процессор, полноценно поддерживающий XSLT 2.0. Учтите, сколько времени прошло с момента выхода последней рекомендации. Да и тематических разработок вроде как и не видно на горизонте. Не думаю, что проект спецификации 3.0 как-то освежит ситуацию: это несерьезно.
Извините, что не комментирую самого проекта: необходимо время на изучение.
Вот видите, сколько смысла можно вложить в несколько слов первого комментария. Думаю, что будь у Вас хоть немножечко из той упорности в старании изъяснять свои мысли чисто, этих глупых минусов недоразумения не было бы.
Что за странная постановка вопроса? Кажется, Вы излишне утрируете: ни от кого таких смешных формулировок я не слышал. Всё зависит от конкретной задачи, и думаю, что каждый мало-мальски опытный разработчик это понимает и учитывает.
Не знаю как насчет разработчиков, но вот абстрактное явление менеджера, который не дружит с пунктуацией, меня настораживает. Не судите строго, но доверие мнению такого профессионала нуждается в дополнительной поддержке.
Можно надеяться, что ваши компиляции начнут слушать исключительно из-за того, что они сведены в Linux. Только, по правде, нужно обладать огромным талантом самовнушения, чтобы после Pro Tools всецело отдаться вышеуказанному ПО.
Весомый аргумент. Только как часто воспроизводится описанный Вами случай? Я, к примеру, неоднократно сталкивался с проблемой недостаточности средств, предоставляемых Ant/Maven, пока не уяснил назначение утилит для сборки проектов. Я, все-таки, твердо уверен в том, что функционал утилиты должен соответствовать заданию, которое она призвана решать.
Да, но ради чего все это? Простота — относительное понятие: кому-то проще описать архитектуру билда с помощью XML.
А Вы, как я вижу, апологет описанного метода. Так какие же значительные плюсы видите лично Вы?
IronRuby, Rake, Albacore и существенные затраты ресурсов на изучение возможностей сих инструментов просто ради того, чтобы отказаться от XML? Мы же не придумываем колесо с целью его придумывания?… Да, возможно XML действительно не наилучшая из альтернатив, но лично я никаких преимуществ в описанном выше способе для себя не разглядел.
Действительно интересный способ применения функции generate-id. По алгоритму вопросов нет, только часть о PHP, как мне кажется, можно откинуть. Ведь предоставленный Вами код может быть обработан любым XSLT процессором.
Да ладно, все это не так важно.
Очень вряд ли: на данный момент мне известен только один процессор, полноценно поддерживающий XSLT 2.0. Учтите, сколько времени прошло с момента выхода последней рекомендации. Да и тематических разработок вроде как и не видно на горизонте. Не думаю, что проект спецификации 3.0 как-то освежит ситуацию: это несерьезно.
Извините, что не комментирую самого проекта: необходимо время на изучение.
Исправьте, пожалуйста.
А Вы, как я вижу, апологет описанного метода. Так какие же значительные плюсы видите лично Вы?