为什么要扩展Xslt样式表功能

基于Xml的可扩展样式表语言Xsl及其转换Xslt实现了将Xml源文件从一种格式到另一种格式的转换。通过在xsl文件中定义一系列遵守规则的模板，匹配这些模板的Xml文档部分就能够被转换为可显示的Html页面文件、符合其他需要的Xml文件或除此之外其他结构的文件。当在Xslt文档中这样做时，没有明显的流程控制，也没有传统编程意义上的算法，甚至不需要任何程序代码和编程语言。绝大多数时候，这能够很好地完成任务。
任何一门语言都不可能绝对完善，而Xsl毕竟只是一门标记语言，单纯依靠它并不能完成所有任务。如同没有XPath、Xslt时，Xml充其量只能是一些标记的集合，什么也不能做一样。尤其，如果我们所需求的不仅仅是改变文档的显示方式或结构，我们还需要对文档进行更多的控制时，单纯使用Xslt的局限性就暴露出来了。比如，获取用户键入的参数以控制转换输出、连接外部数据源以及引用某种计算的结果等等，这些情况下，单纯使用Xslt这样的描述语言无法提供满意的解决方案。而我们知道，程序代码会很轻易地解决这些问题。
使用嵌入式脚本扩展Xslt样式表功能
Xml是易于扩展的，这也正是其短时间内能被广泛接受的原因之一。而Xslt完全基于xml实现，它应该也是易于扩展的。事实的确如此，W3C推荐标准的Xslt提供了针对不同处理器/解析器的专门的扩展。基本上，不同处理器/解析器可以在Xpath表达式、Xslt模板主体内容或顶级元素中使用扩展函数。而且，同任何程序语言的函数/方法一样，这些扩展函数可以用来完成所要求的子功能，它们也能够“一次定义，多次调用”。更重要地，这些嵌入脚本函数不仅能在xslt标记语言中调用，还能够运用在高级语言中。脚本语言所提供的组功能比纯Xslt所提供的功能更丰富，经常可以用来对文档内容进行更复杂的操作（例如对其应用科学计算或访问外部信息源等），这个特性大大扩展了xslt的功能。
实现时，需要在一个指定的命名空间中限定所创建的扩展函数，并且在特定的Xslt处理器中提供实现。之所以必须使用命名空间，是因为命名空间不仅可以防止不同来源的Xslt名称间的冲突。更重要的是它还将扩展予以标识，这样其他的处理器就可以忽略这个专门针对特定处理器的实现，并依靠这个命名空间在Xslt其他部分引用扩展函数。
MSXML XSLT处理器使用元素及其属性implements-prefix实现并扩展函数以提供脚本级支持。微软特别指定的命名空间允许MSXML XSLT处理器在样式表内定位脚本代码。元素的language属性告诉运行期脚本使用哪个解释程序，而implements-prefix属性值是扩展函数的前缀，这个前缀xslt文档的其他地方被声明。定义这些属性之后，Xslt处理器就能够使用这些信息调用解释器运行时脚本（如C#编译器）并在元素中实现扩展函数的代码编写。在样式表的其他地方，依靠元素提供输出的模板通过seletct属性与扩展函数相关联，比如，执行并输出扩展函数的计算结果。
元素定义如下：

其中：
language属性表示语言选项，它与html页面上script元素的language属性极为类似，其值提供函数/方法定义所用的脚本语言。不过，language属性不是必须的，但如果指定，则它的值必须是下列语言之一：C#、VB、JScript、JavaScript、VisualBasic或CSharp。如果未指定，则默认语言为JScript。与其他Xslt元素及属性严格区分大小写不同的是，这里的语言名称不区分大小写，因此，"JavaScript"和"javascript"是等效的。
implements-prefix属性是强制的。用于指定命名空间前缀并将其与脚本块关联。属性的值表示命名空间前缀。前缀所代表的命名空间必须在样式表中的某个位置定义。
同其他任何Xml元素标记一样，元素中的"msxsl"表示命名空间前缀。不过，名字"msxsl"并不重要，也就是说，并不一定非是"msxsl"不可，你一样可以命名为其他的字符串，比如：
xmlns:myxsl="urn:schemas-microsoft-com:xslt" xmlns:myns="urn:schemas-microsoft-com:xslt"
这样，命名空间前缀变为了"myxsl"或者"myns",相应地，元素就将改为或。这种改变不会对结果有什么影响，如果你在你的xslt文档所有部分保持一致的话。（在本文中，所有出现