MSXML的一个令人不爽的地方——M$是故意违背标准的吗?
2004-09-29 15:03
281 查看
9月教XML课程的时候,使用MSXML来做演示。虽然讲课的时候,我说了不少xml标准的发展,并且说各大厂商将会追随标准不断更新自己的产品。然而事实并非如此。M$就是典型。
MSXML SDK,自毕业论文用过3.0之后,就未再接触过。一直到这次才又捡出来MS XML Core Services 4.0。当前MS最新的XML Parser仍然是发布了很久了的 MSXML 4.0 sp2。我原本以为MSXML 4.0已经支持DOM level 2,但是事实并非如此(相反Mozilla支持了绝大多数DOM2模块以及大量的DOM3特性)。
甚至其对DOM level 1的支持也很令人头大。我写了一段代码,显示一个xml node,一般的,需要根据nodeType来做不同的输出:
[/code]
其中namespaceURI是DOM2增加的prop,但MSXML倒也支持。isElementContentWhitespace是DOM3增加的,用来测试文本节点是否为空(即在源xml中的无意义空白),MSXML不支持,但是由于是js,所以也不影响。但是这段代码仍旧不能按照预期运行(本身这个bug就比较隐蔽,需要拿一个较完整的xmldoc进行测试)。
我费了好大劲调试后才发现,msxml居然没有支持node接口上的常量:XXX_NODE。这样就必须直接写值如下:
[/code]
显然,用常量的整数值不直观,对程序维护是个问题(虽然可以像上面一样加上注释)。然而,令人郁闷的是,事实上,msxml是有这组常量的:
IXMLDOMNodeType Enumerated Constants
NODE_ELEMENT(1), NODE_ATTRIBUTE(2), NODE_TEXT(3), etc.
问题是:
它不是node接口下的常量;
在动态类型的脚本环境下,没有办法引用由编译器保障的常量名(至少在SDK中没找到example);
它的命名方式跟DOM规范所列常量名不一致!
尤其可恶的是第三点,规范叫做XXX_NODE,M$偏要叫NODE_XXX,不知道M$是出于什么考虑?!微软故意违背标准来嘲笑标准和标准化组织?M$还有个扩展prop叫"nodeTypeString",返回形如'element'、'attribute'、'text'的字符串,但是就偏偏不肯行举手之劳加上标准中Node接口下所列的常量名。并且,在M$及其盟友的世界,我们丧失了自由权利,故我们也无法做任何修正或补救——除了毫无希望的去祈求M$。
MSXML SDK,自毕业论文用过3.0之后,就未再接触过。一直到这次才又捡出来MS XML Core Services 4.0。当前MS最新的XML Parser仍然是发布了很久了的 MSXML 4.0 sp2。我原本以为MSXML 4.0已经支持DOM level 2,但是事实并非如此(相反Mozilla支持了绝大多数DOM2模块以及大量的DOM3特性)。
甚至其对DOM level 1的支持也很令人头大。我写了一段代码,显示一个xml node,一般的,需要根据nodeType来做不同的输出:
switch (node.nodeType) { case node.ATTRIBUTE_NODE: return "{" + node.namespaceURI + "}" + node.nodeName + ": " + node.nodeValue; break; case node.TEXT_NODE: if (node.isElementContentWhitespace) return ""; else return node.nodeValue; ... }
[/code]
其中namespaceURI是DOM2增加的prop,但MSXML倒也支持。isElementContentWhitespace是DOM3增加的,用来测试文本节点是否为空(即在源xml中的无意义空白),MSXML不支持,但是由于是js,所以也不影响。但是这段代码仍旧不能按照预期运行(本身这个bug就比较隐蔽,需要拿一个较完整的xmldoc进行测试)。
我费了好大劲调试后才发现,msxml居然没有支持node接口上的常量:XXX_NODE。这样就必须直接写值如下:
switch (node.nodeType) { case 2 /*node.ATTRIBUTE_NODE*/: return "{" + node.namespaceURI + "}" + node.nodeName + ": " + node.nodeValue; break; case 3 /*node.TEXT_NODE*/: if (node.isElementContentWhitespace) return ""; //if (node.nodeValue.match(/^/s*$/)) return ""; else return node.nodeValue; ... }
[/code]
显然,用常量的整数值不直观,对程序维护是个问题(虽然可以像上面一样加上注释)。然而,令人郁闷的是,事实上,msxml是有这组常量的:
IXMLDOMNodeType Enumerated Constants
NODE_ELEMENT(1), NODE_ATTRIBUTE(2), NODE_TEXT(3), etc.
问题是:
它不是node接口下的常量;
在动态类型的脚本环境下,没有办法引用由编译器保障的常量名(至少在SDK中没找到example);
它的命名方式跟DOM规范所列常量名不一致!
尤其可恶的是第三点,规范叫做XXX_NODE,M$偏要叫NODE_XXX,不知道M$是出于什么考虑?!微软故意违背标准来嘲笑标准和标准化组织?M$还有个扩展prop叫"nodeTypeString",返回形如'element'、'attribute'、'text'的字符串,但是就偏偏不肯行举手之劳加上标准中Node接口下所列的常量名。并且,在M$及其盟友的世界,我们丧失了自由权利,故我们也无法做任何修正或补救——除了毫无希望的去祈求M$。
相关文章推荐
- 算法导论一个让人很不爽的地方
- 一个每次令人心惊的地方
- WebService又一个不爽的地方
- httpModule的一个很不爽的地方
- VC的一个让人不爽的地方,浪费了我三天时间
- 西藏一个令人向往的地方
- 二分+dp,在一个地方上卡了2小时
- 修改一个方法,应针对所有可能影响到的地方进行测试
- 一个专为移动端开发的原创即时通讯框架,超轻量级、高度提炼,完全基于UDP协议,支持iOS、Android、标准Java平台。
- 编写一个程序,它从标准输入(终端)读取C源代码,并验证所有的花括号都正确的成对出现。
- C# 串口操作系列(1) -- 入门篇,一个标准的,简陋的串口例子。
- 找到一个安静的地方
- ASP .NET中一个可以用来大作文章的地方。
- 结构体定义在一个.h文件之后,只需要在其他的地方引入这个.h就行
- DataList等控件嵌套绑定的一个需要注意的地方
- 这是一个写无责任短评的地方
- stsadm -o export 命令的一个需要注意的地方
- KDevelop开发经验,一个容易出错的地方。
- 一个提供字典下载的地方
- exchange2010把规定时间以前的邮件转移到另外一个地方