tpl等模板語言直接操縱java中的對象, 體現的是圖(Graph)模型, 并通過對象函數封裝了部分動態性. 一般訪問的時候是通過短程關系逐級訪問,例如x.y.funcA().b。利用apache項目組的jxpath包，我們也可以使用類似于xpath的語法在對象圖上進行全局訪問。
xslt使用嚴格定義的xpath語法訪問Tree結構，具有很強的數據操縱能力，例如我們可以通過//mynode等語法輕易的實現節點的聚合，構造出新的結構。在一般xslt包的實現中，都提供了javascript擴展，可以使用javascript構造出的數據節點。

在tpl這樣的模板語言中java中的數據對象結構與tpl中的模板結構（處理規則的結構）是兩分的，而在xslt中輸入數據結構與xslt自身處理規則的機構卻是統一的。實際上tpl這樣的模板語言主要是基于過程語義，即先做。。。，用到。。。，然后。。。, 而xslt對于輸入數據的結構具有明確的全局性假設，主要是一種轉換語義，即不論在什么情況下，只要遇到。。。，就做。。。。在xslt中可以通過xpath語法指定處理規則針對數據（輸入結構）的的觸發條件, 而在tpl中只能通過＜c:decorator＞為tpl標簽指定轉換器，而無法針對數據指定處理規則。

在數據訪問模型這一方面，原則上說xslt與模板語言各有優勢。實際在用于html生成的過程中，xpath的全局訪問和匹配能力一般難以得到發揮，而 xml格式的限制又在一定程度上阻礙了使用靈活的數據供體，這方面模板語言有一定的優勢。但是xslt的約束更強也有本質性的好處，它使用xml數據并輸出xml數據，維護了結構的同質性，便于管道操作。因為假設更明確，xslt對于xml格式的數據的操縱和封裝能力也要強于模板語言。例如它可以使用來為節點追加屬性。

xslt在用于xhtml生成時的一個主要劣勢在于它是對變換規則的分解之后的描述，而我們所希望得到的是最終的結果，即這些規則綜合應用所生成的結果。雖然xslt的語法是xml語言，與xhtml在語法格式上保持了一致性。但是在xslt中，xslt的標簽破壞了xhtml語義上的結構，使得目前無法做到所見即所得。我們不得不在頭腦中運行xslt規則來想象最終的結果，這無疑是痛苦的。模板語言在這方面要輕松許多。

xslt的另一個問題是有時xml語法顯得過于冗長了。在操縱一些局部結構的時候，xml節點并不一定是合適的表達。例如

＜xsl:value-of select=/"x/"/＞ 對比 {x},

＜xsl:call-template name=/"subrule/"＞
＜xsl:with-param name=/"argA/"＞＜xsl:value-of select=/"substring-after(path,/'./')/"/＞＜/xsl:with-param＞
＜/xsl:call-template＞
對比
＜my:subrule argA=/"{path.substringAfter(/'./')}/" /＞

在調用子模板方面，顯然xslt封裝的抽象層次也要弱于tpl模板語言。

xslt作為一種xml格式的結構變換語言，維護了xml世界的概念完整性，其意義無疑是重大的。但并不是所有時候xml都是最適的描述模型。我們最好還是將它與其他技術結合使用。目前在witrx平臺中，我們對于xslt的使用主要是對tpl模板進行布局和過濾處理，即xslt用于對處理規則進行變換，而將根據數據生成html這個最細致的工作留給過程處理能力和封裝能力更強的tpl模板語言。