所见略同:Native XML Scripting

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):

  1. 直接的 xml literals (如:var x = <simple-doc/>)
  2. 借用操作符 .  表示类似xpath的 /
  3. 增加操作符 .. 表示类似xpath的 //
  4. 支持类似xpath的filter(如:a.b.(c.@id == 100 && d > 27))
  5. 直接使用js的循环语法构造如 for (key in list)
  6. 支持xml的修改(这是xslt和xquery不具备的)
  7. 可以用 {} 嵌套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。

你可能感兴趣的:(xml,语言,groovy,XSLT,scripting,Literals)