em markup de novo simplesmente pra garantir que esteja bem formado me parece MUITO overkill.Eu trabalhei muito tempo no governo e sei que e dificil conseguir agregar um ferramental novo ao trabalho, mas ainda acho que vale o esforco de tentar utilizar algo que ja esta estavel e e amplamente aceito pela comunidade do que construir algo do zero.Thiago Mata responde...Primeiramente seu comentario e muito pertinente. A resposta que eu vou lhe passar devo colocar na propria documentacao do projeto mas talvez ainda assim faca um adendo no post falando disso.Conforme voce ja deve ter notado, a solucao que fizemos foi muito similar ao Jsf http://exadel.com/web/portal/jsftags-guide, Seam, ColdFusion, JLibs http://code.google.com/p/jlibs/wiki/XMLDocument, entao vou evitar ser repetitivo e dizer que os pontos positivos e negativos dessas solucoes sao bem proximos. Basta uma busca sobre Jsf ou Jlibs e voce vera pessoas defendendo e apoiando conforme o contexto. Apenas ressaltando que na nossa implementacao, foram mantidas os nomes e os atributos das tags do html.Apesar do custo das conversoes Xml => OO => Xml ser de fato um custo grande, a diferenca em termos de tempo resposta, mesmo quando fizemos simulacoes de varios milhares de acessos simultaneos, nao foi tao grande ao ponto de ser considerado impeditivo, tendo em vista o porte das maquinas que temos. Mas compreendo que isso pode nao ser o caso em outras empresas.Utilizar esse recurso de Xml => OO => Xml nos permite muito mais do que apenas validar o Xhtml, esse foi um dos argumentos do post que ja estava muito extenso. Esse argumento se mostrou importante aqui na empresa por que foi uma das reclamacoes que nossos usuarios finais fazem dos nossos sistemas. Como estamos ainda tendo que trabalhar com fabricas de softwares, controlar a qualidade do xhtml gerado e essencial. Lembre-se que temos sistemas em que os usuarios sao deficientes visuais ou com inabilidades motoras onde uma pagina html mal feita pode ser impeditivo ao uso.Dentre outras vantagens dessa solucao temos o encapsulamento de componentes complexos de tela em objetos. Podemos ter as tags personalizadas como etc. E, a mesma validacao que funciona nas tags do xhtml, ira validar se os campos de cada uma dessas tags foram adequadamente preenchidos, assim como ja esta funcionando com as tags de template. A criacao dessas tags personalizadas pode ser feita utilizando outros templates combinados com comandos DOM, ou fazendo uso apenas de objetos e DOM, etc. Tudo isso utilizando as vantagens de uma organizacao OO. Essa capacidade de encapsulamento de complexidade e padronizacao de arquitetura de modo intuitivo no template foi uma das melhorias solicitadas para a nossa equipe.Se voce avaliar o exemplo da tag personalizada Number que utilizei no post, ira notar que uma tag no meio do conteudo adicionou um script no head. Entao, conforme pode ser visto nesse exemplo, as tags podem interagir entre si, adicionando ou alterando o comportamento de tags anteriores. Com isso nos podemos fazer, por exemplo, paginas que facam carga apenas dos arquivos javascript e css que forem ser utilizados. Podemos tambem fazer facilmente que uma tag especial seja a soma dos