http://dev2dev.bea.com/products/wlworkshop/articles/JSchneider_XML.jsp
本来想写“预言成真”，因为我跟pt描述过我的想法，即专门的xml编程语言。不过这篇文章的时间恐怕比我形成这个想法要早，所以为免成为事后诸葛亮，俺就用“所见略同”作为标题了。:P
言归正传，文章作者据说是在ECMA领导E4X(ECMAScript for XML)标准——又题外话：那个下一代ECMAScript Edition 4 (aka JavaScript 2.0)都那么多年了，还是没有完成的迹象，俺都等的不耐烦了——不过我却没在JS2的介绍ppt上看到这个特性。
其主要就是在js中加入直接的xml支持（first-class citizen）：
直接的 xml literals （如：var x = <simple-doc/>）
借用操作符 . 表示类似xpath的 /
增加操作符 .. 表示类似xpath的 //
支持类似xpath的filter（如：a.b.(c.@id == 100 && d > 27)）
直接使用js的循环语法构造如 for (key in list)
支持xml的修改（这是xslt和xquery不具备的）
可以用 {} 嵌套js表达式（<doc>{a+b}</doc>）
将其与几个内置xml支持（当然也算native xml scripting）的语言比较，如php5的simpleXML模块和Groovy。可粗略总结出几个设计的考量：
xml输出：xml literal和script的简易嵌套结构，主要目的是用于xml的输出。e4x是从xslt中目标属性的缩写法开始到xquery发扬光大的{}结构。而php本身已具有便利的嵌入式语法，故没有这额外的设计。groovy在一般的嵌入式语法之外，多了一种利用closure的markup builder的方法，也没有这种设计。
xml树遍历和过滤：基本的做法是转换到object，然后再利用语言本身的遍历特性（array, list, map等的）。groovy的gpath的说法是向xpath看齐。我个人感到gpath的一个问题是某些地方有混淆，比如在一个gpath上如何区分 findAll方法和一个叫做findAll的元素（尽管可以通过findAll后必然跟一个closure来判断）。此外它似乎没有//的等价方法。 e4x使用..作为//的对应，虽然也符合逻辑，但是总感觉不习惯（因为xpath里面用..表示父）。php的一个特殊之处是不像js或者groovy 中.和[]是等价的，它使用->来获得元素，用[]来获得属性，而不是直接借用@attr的表示法，此外它不支持直接的过滤（不过有-> xpath的语法可，有需求可以直接用xpath）。基本上，从expression的简洁和表达力上，现有的都与xpath有较大差距。个人感觉，直接利用xpath语法可能更好。
最后，我最初的想法，和上述考察过的现有实践有些不同，即，我主要考虑完全针对xml的语言，而不是现有的OO或准OO语言如何最方便的操作xml。
