Is MSXML a uncomfortable place - M $ is deliberately violated?

xiaoxiao2021-03-06  58

When teaching XML courses in September, use MSXML to make a demonstration. Although I said, I said a lot of XML standards and said that major manufacturers will follow standards to update their products. However, it is not. M $ is typical.

MSXML SDK, after the graduation thesis has been used in 3.0, it will not be contacted. I have been in this time, I will pick up MS XML Core Services 4.0. The latest XML Parser, the latest MS is still published MSXML 4.0 SP2. I originally thought that MSXML 4.0 has supported DOM Level 2, but the fact is not that (in contrast Mozilla supports the vast majority DOM2 module and a large number of DOM3 features).

Even the support for Dom Level 1 is also very big. I wrote a code, showing an XML Node, general, need to do different outputs according to 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;

...

}

Where Namespaceuri is a DOM2 added PROP, but MSXML is also supported. ISELEMENTCONTENTWHITESPACE is DOM3, which is used to test whether the text node is empty (ie, in the source XML inadequilly), MSXML does not support, but because JS, it does not affect. However, this code is still unable to run in accordance with expected operation (itself is more concealed, you need to take a more complete XMLDoc to test).

After I spent a lot of debugging, I found that MSXML actually did not support the constant on the Node interface: XXX_Node. This must be written directly as follows:

Switch (node.nodetype)

{

Case 2 /*node.attribute_node/:

Return "{" node.namespaceuri "}" node.nodename ":" node.nodevalue;

Break;

Case 3 /*ode.text_node*/:

IF (Node.ISElementContentWhitespace) Return ""; // if (node.nodeview.match ";"

Else return node.nodevalue;

...

}

Obviously, the integer value of constants is not intuitive, and the program maintenance is a problem (although it can be added like the above). However, it is depressed that in fact, MSXML is this set of constants:

IxmldomnodeType Enumerated Constants

Node_Element (1), Node_attribute (2), Node_Text (3), ETC.

The issue is:

It is not a constant under the Node interface; in the dynamic type script environment, there is no way to reference the constant name of the compiler guarantee (at least an example in the SDK); its naming method is inconsistent with the Some constant name listed in the DOM specification! Especially awful is the third point, the specification is called XXX_Node, M $ is asked to name node_xxx, I don't know what M $ is what is considered? ! Microsoft deliberately violates standards to laugh at standards and standardized organizations? M $ also has an extended prop called "nodetypeString", return, such as 'element', 'attribute', 'Text' strings, but will not be willing to raise his hand to add the constant name listed under the Node interface in the standard. And, in the world of M $ and its ally, we lost our own rights, so we couldn't do any amendments or remedies - except for unworthy to pray M $.

转载请注明原文地址:https://www.9cbs.com/read-111811.html

New Post(0)