А смысл? Сервис должен отдавать минимум инфы, конкретно то, что запросили. Зачем генерить объёмный документ со всей лажей, типа менюшек (не зашивать же их в стили)? Если кто так делал, поделитесь с народом как галимо это было, только честно 

Вебсервис должен уметь отдавать только требуемую инфу в XML/JSON. Движок должен генерить полноценный XHTML документ (траф экономить на вёрстке это не разумно, нужно хорошо верстать  ). Документ собирается разными компонентами, которые могут использовать для своих частей всё что угодно, от темплейтера, до XSLT.

Т.е. всё на стороне сервера ты предлагаешь делать? Т.е. не доводить до преобразования до XSLT  на клиенте(браузере)? Какие аргументы против у тебя?

Сразу определимся, я не против XSLT и даже активно использую, но не для всей страницы целиком. Главная проблема это собрать полный документ со всей инфой, встречаемой на странице. Элементарно представь статью, справа новости/анонсы, менюшки и прочее, всё это не зашито, а добавляется по мере жизни проекта.

Тут два пути, либо собирать страницу из кучи XML ресуросв (document()), но тогда вся система должна быть просто идеально спроектирована по вебсервисам (требуется работа мастера, редко встретишь). Некоторые сложности будут во взаимодействии между сервисами, например у меня (ещё не готово) меню строиться "компонентом движка", к которому любой другой может обратиться и сказать что сейчас показываем (формально идентификатор ресурса + параметры). Менюшка подсвечивает опции + эта же меню с другого view рисует хлебные крошки. Это всё в одном запросе, т.е. быстро и просто. Теперь представь как ты реализуешь "хлебные крошки" имея туеву хучу разрозненных сервисов? Оцениваем все сложности 

Второй путь это строить "обычный движок", где каждый копонент "рисует" в XML канву. Тогда документ представляет из себя массу контейнеров с аннотациами. XSLT стили получаются сложными, потому как в обрабатываемом документе может встретиться всё что угодно. Главное это ограниченность общего контейнера/документа, ведь если продумаешь всё до деталей, то XML получиться через чур сложным (не меряное количество "мета инфы"). Таже новый компонент как то должен публиковать свои XSLT стили, согласовывать их со всеми остальными. Т.е. всё упирается в реально прямые руки программиста/проектировщика.

А теперь задумались будет ли легче писать новый компонент к такому движку? А что конкретно полезного несёт "фанатичное использование XML"? А что реально полезного? А кто реально писал компонент под такую систему, доставал из канвы нужный контейнер, собирал DOM'ом поддерево? Матерился когда дескриптивные возможности документа оказывались ограниченными, а менять схему нельзя под страхом смерти? А кто переписывал десяток компонент после очередного изменения схемы документа, ибо "чистым DOM'ом собирали"? А кто пил капли когда писал XSLT под этот "через чур гибкий" документ? А оно вам надо? 

ИМХО вывод: используйте инструменты там, где они дают вам преимущество. Пишите раппорт в XML, потому что схема точно известна, трансформацией в XSL-FO -> (PDF/ODF/.rtf/.doc) легко получить что требуется. Не пишите веб страницу целиком в едином XML. Иногда шаблонизатор проще, зачем делать зря жизнь сложней? Аргументы против? 

Кстати шаблонизатор при может иметь не плохие функции форматирования, например "произносить" даты словами, деньги, расставлять падежи/словоформы и т.д.

К примеру сейчас преписываю шаблонизатор (черновик, в конце бред), этакий merge языкового пакета (gettext like + форматтеры из моего другого поделия) и шаблонизатора. В идеале код не должен содержать текста вообще, всё обслуживается view объектом, который пользует интернациональный шаблон.