上班几个月了，才发现公司里没人使用xpath, 而经过实验，xpath是完全可以使用的。。。绝不会带来任何麻烦，而且效率要高得多。原因是公司里的人都对XPATH了解不多。都是用 dom 的 getElementByTagName, nextSibling 这些Dom methods 来 navigate dom object. 当然，他们写了很多function， 结合regular expression, 也能相当快的找到要找到NODE. 但比起xpath来，显得低效，而且繁锁。
昨天发现Xpath本来就是被 xmldom 所支持的，使用它并不会对我们的程序有什么影响，今天便试了下。
真的方便很多，可是却好像有些函数使用不了。比如 matches, contains等。试了几次都不行，觉得奇怪。搜索了好久，好发现要加这句
objTP.SetProperty "SelectionLanguage", "XPath"
神了，用了这句， matches可以用了。。。但是， 原来写好的xpath都不起作用了。。。晕。。。
于是，我想，既然现在把 SelectionLanguage 设成了XPath, 而且原来写的xpath 反而不能用了，那原来用的肯定不是xpath. 既然有setProperty, 一定也有 getProperty, 于是， 我便 wsh.echo objTP.GetProperty "SelectionLanguage", 于是，我发现，原来使用的并不是xpath, 而是一种叫 xslpattern 的东西。只不过它的写法几乎和 xPath一模一样。 只不过它并不支持 Xpath的函数。 这就是为什么我用不了 xPath函数的原因。
只是设成Xpath后，我原来写的pattern居然无效了。。。很奇怪。。。
于是我突然觉得xPath很复杂， 还是 xslpattern好些， 便拼命的在网上搜索关于 xslpattern 的东西， 希望能找到它的文档， 希望它也有类似matches的函数。在网上找了半天，发现关于它的东西实在太少了。不好最好我好像还是找到了。。。
不过，我同时找到了为什么用XPath反而不工作的原因。
问题就出在name space, 我想很多朋友都被这个xmlns 困惑过。 因为有了 xmlns 这个attribute后，我们就不能原来那样用xpath了。而是要先定义一个 name space.
定义过name space 后， 在 xpath query 里面，还得用上它。
for each objTagDiv in objTP.selectNodes(".//cf:div[@id='TopMenu']")
原来只要写 //div 就可以，现在却要写 //cf:div 了，而且每个child node 都得加了 cf: 在前面， 实在麻烦。
而 xslpattern却没有这个麻烦，它跟本不认识 xmlns.
但它毕竟是过时的东西了，我不能背着时代的潮流走，所以我还得在xpath上下点工夫。
呵呵，不过我有更邪恶的方法，我打算在loadXML之前， 把 xmlns这个attribute 删掉。那就无后顾之忧了。
--
Feng
