[denver]

Hubbitus
Насчет противоречий двух фраз - не вижу никаких противоречий. Если верстальщик понимает XSLT то XSLT его не шугает А то что учить XSL придется я посчитал как раз за минус.

а валидный XML на PHP не теми же str_replace'ами и preg_replace'ами создать придется?

Валидный XML не так уж и сложно производить: берем $var и записываем как "<".$foo.">".htmlspecialchars($var)."</".$foo.">". Единственное несложное правило
str_replace не нужен. т.к. никакого шаблона самого XML не существует. В каждом php файле (ну т.е. для каждого типа страниц) будет свой, таким каким захочет его сделать программер (будем считать что программер тут имеет выбор), в идеале -- таким который отвечал бы логике страницы -- (представь например идеальную страницу топика без любого форматирования и выведи ее). В конце концов выводишь ты не для человека, еще раз напомню -- это промежуточный вывод.

Насчет скорости XSLT -- надо тестировать, я не зря говорил о гипотетичной быстроте процессора XSLT, т.к. процессор процессору рознь. Есть слухи что в PHP5 он намного быстрее чем sablotron из PHP4. И дальше скорее всего он тоже будет оптимизироваться. Но не исключено что и в PHP4 скорость парсинга PHP->XML->XSLT->HTML быстрее чем парсинга Smarty->PHP->HTML, только по тому что шаг XML->XSLT->HTML делается одной функцией: echo xslt_process($xml, $xsl). Мне вот подсознательно кажется что одна функция лучше чем много других Уравняем шансы договорившись что результирующий HTML будет одинаковый, соответсвенно сложность Smarty кода будет примерно равна сложности XSLT. Однако это очевидо что код Smarty-"процессора" написан на PHP, а код XSLT-процессора на языке более (если не самого) низкого уровня. Надеюсь я понятно аргументировал.

это ли уже будет в итоге не программированеи вывода, только верстальщиком????

Тут ты верно подметил. Просто вы не говорили еще о следующем и я не стал указывать. Но таки в проблеме "шаблониовании" подразумевается какой-либо один из двух подходов (или двух проблем):
1. Отделение PHP кода от HTML кода.
либо
2. Отделение бизнес логики от логики отображения.
При чем, подчеркну, это не одно и то же. Первый подход это и есть путь FastTemplate, в шаблонах нет PHP кода, однако изменить логику отображения не удастся верстальщику не пнув программера чтобы тот внес изменения туда где в идеале должна быть только бизнес логика -- в коде PHP.
Второй подход -- это как раз Smarty и XSLT. В их шаблонах тоже нет PHP кода, однако логика отображения может менятся вне зависимости от программера с его кодом.
Конечно координация между верстальщиком и программером нужна всегда, вопрос лишь в том что во втором подходе они не координируют уже те вещи которые относятся (по крайней мере должны относится) только к одному из них. Например не будут таких запросов как "Верстальщик: мне нужно чтобы в переменную $color парсилось #FFF если ячейка четная и #000 если наоборот".

Другой вопрос -- что тебе важнее разделять. Быть может с этого и надо было начинать? Иногда (а в идеальном, портируемом коде -- всегда) лучше не засорять PHP переменными содержащими цвета элементов и все такое остальное (субъективное). Вот в таком случае без знаний некого третьего языка -- языка управления отображением не обойтись, будь то Smarty или XSLT.

RaZEr

XML будет посложнее в реализации.

1. Мой XML'ный движок под саблотрон содержит 70 строчек кода (xml.lib.php). При этом для страницы выдающей HTML c основой иксэмэля такого вида:

<page>
	<class>topic</class>
	<posts>
		<post>
			<user>denver</user>
			<message>bla-bla-bla</message>
		</post>
		<post>
			<user>RaZEr</user>
			<message>RTFM</message>
		</post>
	</posts>
</page>

PHP буквально следующий:

PHP код:

<?
require('xml.lib.php');

$xml = new block('page', array(
    element('class', 'topic'),
    new block('posts', array(
        new block('post', array(
            element('user', 'denver'),
            element('message', 'bla-bla-bla')
        )),
        new block('post', array(
            element('user', 'RaZEr'),
            element('message', 'RTFM')
        ))
    ))
));

echo $xml->output("/xsl/topic.xsl");
die("<!-- page generated ok -->");

Ну естественно в реальности масив заполняется в цикле, на основании данных из БД. Затем уже делается:
$page->include('posts', $posts);
$xml->include('page', $page);
или что-то типа того. Т.е. не так уж много кода, а XML тем не менее выдается валидный.
Понятно что результирующий HTML очень может даже походить на HTML страницы данного топика (чуть больше элементов добавить), но очевидно что код PHP все равно будет меньше чем если бы он был под FastTemplate (учитывая всю специфику imho.ws топика - вывод зебры, навигации, текущего раздела и т.п.).

То хостер консерватор-придурок не ставит нужные расширения

Это дело времени (или другого хостера).

то любимая программка не понимает UTF-8

О кодировке вообще речь не идет. XML и иже абстрактен от кодировок.

то клиент хочет сам редактировать HTML, при этом икая услышав "W3C Recommendation" или "Valid XHTML".

Если речь идет о некоей CMS то клиентский код вставляем обработав его htmlspecialchars(), сойдет т.к. придерживаться XHTML обязательно только в XSL файлах, а результирующий HТML может быть хоть трижды невалиден (при желании ).
Если же речь идет о том что клиент (зная HTML или наняв дешевого верстальшика) хочет править шаблоны, то тогда согласен, XSLT не подходит.

В любом случае (кроме последнего) все проблемы не являются боьльшими проблемами и решаются сегодня.