Давайте может исключительно XML+XSLT использовать? Т.е. выдаем весь контент в XML всегда. И всегда для него есть конкретный XSLT-парсер.

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

Проблема заключается в другом - в рациональности такого подхода. Ведь когда нужно что-то простое вывести на экран гораздо проще вывести сразу HTML, а не раздельно XML и XSLT. Что думаете по этому поводу?

ИМХО ничего страшного в разделении для "простых" вещей нет. А ХТМЛ всегда и так можно выдать.
Делйте сразу XML / XSLT и желательно с клиентским парсингом. Быстрее, надёжнее, правильнее.
Добавлено @ 20:34
Во всяком случае этот подход будет являтся коренным отличием от всех остальных CMS.

Да,. я вот тоже так думаю... Парсинг конечно я бы тоже переложил на клиента. Есть такая система: SiteBuilder. В ней используется также XML и XSLT, однако парсинг на сервере они почему-то делают. Почему - это большой вопрос...
Добавлено @ 20:38

Именно. Имеет смысл делать CMS, только если с самого начала сейчас ее начать строить на новых технологиях. Что и хочется сделать. Очередной клон какой-то CMS cмысла создавать нет. Поэтому я предлагаю с самого начала все МАКСИМАЛЬНО продумать и задукоментировать ядро системы.
Так, чтобы любой разработчик мог легко писать к ней модули.

Потому что не все браузеры поддерживают. Точнее опера < 9.0 не поддерживает. Вот для них можно на сервере делать.
К тому же технология вообще не широко применяется, потому что очень новая. Но практика показывает, что это всё прекрасно работает.

Вот тут есть данные о поддержки браузерами: http://www.w3schools.com/xsl/xsl_browsers.asp

и тут: http://svn.code-host.net/browser-tests/
Добавлено @ 21:00

А насколько это сложно на сервере делать?

Вот к этому надо подойти очень ответственно!!!

Так.. А что делать с шаблонами и шаблонным языком? Если мы используем XSLT, то нам вообще не нужен никакой шаблонный язык больше??

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

Для простых вещей можно внести в Framework простой шаблонизатор, для подмены пары значений в HTML.

Отлично! Как с твои классом можно будет работать? Может какой интерфейс использовать?

Wowa, с моими классами работать нельзя будет. К сожалению в РНР 5 из екстеншина DOMXML исключили функции отвечающие за xslt преобразования. Сейчас начал переписывать под 5 -ку для ext. DOM.
Работа класса несомненно будет строиться на интерфесах. Мне очень это помогло с DOMXML. Сокращает объемы кодинка во много раз.

интересно, почему...

Wowa, видимо из-за некоторой несовместимости DOM и DOMXML в РНР 4 и 5. Предпологаю что из-за того что и DOM и DOMXML используют одну модель для работы с XML данными, и эта модель различается в разных версиях.
Хотя может я не подключил какие-то либы у себя... я своего хостера просил поставить для 5ки DOMXML, пока не сделали, сказали позже отпишутся. Если поставят и там будет работать, значит я чего-то не до подключил.
Добавлено @ 23:52
Насколько я понял из мануала, в РНР 4 использовать нужно класс XsltProcessor (http://php.rinet.ru/manual/ru/function.domxml-xslt-stylesheet-doc.php).

Wowa, 
Не нужен никакой класс, все делается через extension: http://ee.php.net/xsl

Это и есть XSLTProcessor о котором я говорил) екстеншн в виде класса.

Используем DOM + XSLTProcessor и проблем не будет.
В некоторых случаях обработка на сервере будет не нужна, все будет зависить от поддержки XSLT преобразований клиентом.

Ребята, а как мы будем делать, например, веб-ссылки в XML-документах? Ведь disable-output-escaping в Firefox не поддерживается...