An unpleasant part of MSXML-Does M $ intentionally violate the standard?

When teaching the XML course in September, MSXML is used for demonstration. Although I spoke a lot about the development of XML standards during the lectures, I also said that major manufacturers will follow the standards to constantly update their products. However, this is not the case. M $ is typical.

Msxml sdk, which has never been used since I used 3.0 of my graduation thesis. It was not until this time that Ms XML Core Services 4.0 was found again. Currently, Ms's latest XML parser is still MSXML 4.0 sp2, which has been released for a long time. I originally thought that MSXML 4.0 already supports Dom Level 2, but this is not the case (on the contrary, Mozilla supports the vast majority of dom2 modules and a large number of dom3 features ).

Even its support for Dom Level 1 is very impressive. I wrote a piece of code to display an XML node. Generally, different output needs to be made based on 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;        ...    }

Among them, namespaceuri is the prop added by dom2, but it is also supported by MSXML. Iselementcontentwhitespace is added by dom3 to test whether the text node is empty (that is, meaningless blank in the source XML). MSXML does not support it, but it does not affect it because it is Js. However, this code still cannot run as expected (the bug itself is relatively concealed and requires a complete xmldoc for testing ).

After debugging, I found that MSXML does not support the constant xxx_node on the node interface. In this way, you must directly write the following values:

    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;        ...    }

Obviously, the integer value of a constant is not intuitive, and maintenance of the program is a problem (although it can be annotated as above ). However, it is depressing that, in fact, MSXML has this set of constants:

Ixmldomnodetype enumerated Constants

Node_element (1), node_attribute (2), node_text (3), etc.

The problem is:

1. It is not a constant under the node interface;
2. In a dynamic script environment, there is no way to reference the constant name guaranteed by the compiler (at least example is not found in the SDK );
3. Its naming method is inconsistent with the constant names listed in the DOM specification!

The third thing is that the specification is xxx_node and M $ is node_xxx. I don't know what the M $ is ?! Does Microsoft deliberately go against standards to laugh at standards and standardization organizations? M $ there is also a extended prop called "nodetypestring", which returns strings such as 'element', 'attribute', and 'text, however, it is not feasible to add the constant names listed in the standard node interface. In addition, in the world of M $ and its allies, we lose the right to freedom, so we cannot make any amendment or remedy-except pray for M $ without hope.