微软真的挖了很多坑，可能就像任正非说的，在90年代进入了无人区，差不多十年多时间有精力没有地方撒，无法判断前进方向，推出了很多错误的路线。现在遇到的 XLST 就是一个大坑。
XLM 在 00 年后开始热炒，这种标记性语言在技术层面确实有一定的价值。它是一种更根本的盒式标记性语言，比起HTML，它可以更好的表达数据。这个语言就像 LISP 一样，看起来很根本，使用可以非常灵活。这种东西是考验架构师/产品经理的重要关口。从市场来看，当时微软有很强的技术号召力，微软不是一家纯粹的我做产品给你用的公司，它很早就开放了API给开发人员做 Windows 应用，且推出了重磅级的开发工具。微软对开发人员的关注是非常大的，我们知道微软在 Java 之战后继续把焦点放在了面向对象这个方面，花了很多价钱在 .NET 上。
XLM 和 .NET 有什么关系呢？其实没有太多关系。XML 是一个标记语言，它的功能是传递结构化的数据，既然是传递数据就好好传递数据不好吗？不，当时的观念是 HTML 也是 XML 的一种，HTML 能做的 XML 也要能做，XML 要成为一种更根本的 HTML。它要有自己的样式表以便显示到UI。纯粹 XML 已经被定义为了数据载体，不适合放 UI 层，HTML 把 CSS JS 混在一起的做法是草台班子的搞法，新的XML必须避免这个坑，这样就发明了一种 M -> V 转换专用 XML，这就是 XLST。 XLST 实现了数据到UI的渲染定义，当渲染复杂时，还可以使用 XLST 编程，XLST 支持
在搞 .NET 的同时推出这么一个技术，真是自乱阵脚。的确，从理念来说，用 XML 也能做一切，只要有一个图灵完备的解释器就OK，甚至可以推出一个 XML.NET 语言。
XML 为什么失败了呢？其实作为数据表示语言 XML 也不能算完全失败，但是 XLST 的确真的失败了，而 XLST 一旦失败，XML 也就仅仅只能作为一个数据语言来用，最终它就只能和 JSON,yml 之类 PK，谈成功失败都没有太大意义，微软根本不值得花精力去折腾它。那么 XLST 为何失败呢？
XLST 失败的直接原因是 AJAX 的大规模应用，新登上舞台 JavaScript 只需要把 XML 当数据来用就可以实现 XML -> UI 了，并且 JS 还可以做更多。
但是它的失败其实是注定的。回顾起来 XLST 的特点是，它想把其它语言已经做到的东西用一种新的方法实现，这种方法还更蹩脚，这和 Excel Macrosheet 很像。Macrosheet 图灵完备，还可以使用 API 编程，甚至靠它就可以出窗体了。但这种“技术突破”却是公司精力的虚耗，你没有办法让市场大规模接受，你愿意花大价钱花很大的成本推当然也会有几个接受的人，但这些接受你的烂理念的人总有一天会发现，这个东西只能当玩具，然后非常恨你，形成负面口碑。而这些技术往往还会挖很多的坑，因为它是图灵完备的，能运行在客户机上，就会出现用它开发的各种恶意软件和病毒。可能当时很多人没有注意到，XML 有点像 LISP，语言特性很少但是非常完备，而 LISP 早已证明完备不等于好用，一方面人类不是机器，另一方面从低阶的完备到高阶的场景适应能力还有很长一段路，完备只能当毕业设计，适应场景才能真正赢得市场。
btw. 从这个角度出发也的确可以理解苹果禁止动态运行 JavaScript 的做法了，对程序员来说它可以动态升级，但对客户来说这是非常危险的，手机里放着客户的重要信息，不是一个电子玩具。当然更好的办法苹果应该发明一种普遍的手段检测恶意行为。
具体一点说，我们可以看到，XLST 的特点是模式匹配后执行一段代码，这些代码就专门操纵数据节点，可以看出这玩意儿一点面向对象的思维都没有，只是一组转换器函数的合集————你起码把 XLST 称为一个对象也算有点头脑————这套可悲的定义把它的应用范围极大的局限于转换，这就注定了它无法取得成功。
XML 真是一个悲伤的故事，从 XML 开始一个微软鼓捣一点新东西就会形成一股龙卷风的时代过去了。
继续折腾了一下 XSLT，它的作用是从 XML 输出 HTML 或者 TXT，这种功能照现在来看在 JSX 可以很好的处理，这也是声明式编程没落的一个案例。
XSL 致命的缺陷是它的操作都是围绕 XML 节点展开，不是面向对象的，整个XML风潮都有这个问题。