所見略同：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。