msxml中的错误？要求确认。 [英] bug in msxml? confirmation requested.

问题描述

您好，


任何人都可以确认是否存在以下影响，我会考虑根据w3c将
作为msxml中的关键错误的xpath规格？


规范说：

父母，祖先，祖先或自我，先前和前兄弟

轴是反向轴
http://www.w3.org/TR/2005/CR-xpath20...th-ReverseAxis


但是，实现仅在使用固定索引使用
时以正确的顺序访问这些轴。在谓词中使用轴或通过节点集循环使用时，轴恰好以错误的顺序排出

（评估顺序正确，节点集人口不是）。


请考虑以下示例文档：

< root attrib =" testroot">

< ; first attrib =" testfirst">

< second attrib =" testsecond">

< third attrib ="" />

< / second>

< 4th />

< / first>

< / root>

以下XPath语句应从第三个元素循环到

根：

"祖先或自我:: *"

XPath规范说结果必须是：第三个，第二个，第一个，最后是

root，从第三个元素开始。相反，输出将是root，

第一个，第二个，最后是第三个msxml。

这真的很糟糕。有人可能会在编程上通过一个节点集迭代它，但是当它在

直接路径中用作条件时，结果将不会如预期的那样。

只考虑以下情况：

任务是评估最佳属性attrib。从第三个元素

向上，即找到一个在属性中有一些价值的祖先元素。

我想使用：

return thirdElement.SelectSingleNode（" ancestor-or-self :: * [string（@attrib）！=

''''''）。）。值;

但我不能因为它总会返回testroot。因为这是错误订单中的第一个

元素。


此示例代码可以重现错误：


// ---------------------------

//演示（控制台应用程序）：


使用System;

使用System.Xml;


名称空间Trash.XmlTest

{< br $>
class program

{

static void Main（string [] args）

{

XmlDocument doc = new XmlDocument（）;

doc.LoadXml（

@"< root>

< first>

< second>

< third />

< / second>

< fourth / >

< / first>

< / root>"）;

XmlElement element =（XmlElement）

doc.DocumentElement.SelectSingleNode（" // third"）;

foreach（xmlElement e in

element.SelectNodes（" ancestor-or-self） :: *"））

Console.WriteLine（e.LocalName）;

Console.Re adLine（）;

}

}

}


//输出：


root

优先

秒

第三


/ /右：第三，第二，第一，根

// ------------------------------ -------


如果这确实是一个错误，有没有人知道一个错误修正或在哪里发布一个

报告来修复？我想知道我这里是否有问题。


我是唯一一个经历过这种行为的人吗？根据
http： //www.google.com/search?q=msxml...tor-or-self%22 我不是。

在这种情况下，为什么还没有修复？这不仅仅是一种化妆品，而是一种b $ b b无序。我发现了一个类似的错误报告已经确认并且显然已修复（？）微软用于MSXML核心服务4.0（MSXML 3.0）。


我正在运行VS 2005 XP Pro SP2上的+ .NET 2.0（MSXML 6.0），包含所有

更新，补丁，修复程序和其他内容。是否有可能最近的更新

恢复旧的错误？


- 有谁知道MS是否已经确认了这个？

- 有没有其他人经历过这些影响，虽然这个问题可能不会在所有情况下都被认可？

- 哪些可以解决这些问题？


在此先感谢，

Matt

Hello,

can anyone confirm the existence of the following effects which I''d consider
being a critical bug in msxml according to w3c''s xpath specs?

The Spec says:
"The parent, ancestor, ancestor-or-self, preceding, and preceding-sibling
axes are reverse axes"
http://www.w3.org/TR/2005/CR-xpath20...th-ReverseAxis

However, the implementation only accesses these axes in the right order when
using fixed indices. When using the axis in a predicate or when cycling
through a nodeset instead, the axis happens to be put out in the wrong order
(evaluation order is correct, nodeset population is not).

Consider the following sample document:
<root attrib="testroot">
<first attrib="testfirst">
<second attrib="testsecond">
<third attrib="" />
</second>
<fourth />
</first>
</root>

The following XPath statement shall cycle from the third element to the
root:
"ancestor-or-self::*"
The XPath spec says the result must be: third, second, first and finally
root, when beginning at third element. Instead, the output will be root,
first, second and finally third with msxml.
This is really awful. One might work around it when programmatically
iterating through a node-set, but when using it as a condition in a
straight-forward path the results will not be as intended.
Just consider the following case:
The task is to evaluate the best attribute "attrib" from the third element
upwards, i.e. find an ancestor element that has some value in the attribute.
I''d like to use:
return thirdElement.SelectSingleNode("ancestor-or-self::*[string(@attrib) !=
'''']").Value;
but I can''t since it will always return "testroot" because this is the first
element in that wrong order.

This sample code can reproduce the bug:

// ---------------------------
// Demo (Console Application):

using System;
using System.Xml;

namespace Trash.XmlTest
{
class Program
{
static void Main(string[] args)
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(
@"<root>
<first>
<second>
<third />
</second>
<fourth />
</first>
</root>");
XmlElement element = (XmlElement)
doc.DocumentElement.SelectSingleNode("//third");
foreach (XmlElement e in
element.SelectNodes("ancestor-or-self::*"))
Console.WriteLine(e.LocalName);
Console.ReadLine();
}
}
}

// Output:

root
first
second
third

// Right: third, second, first, root
// -------------------------------------

If this is indeed a bug, does anyone know about a bugfix or where to post a
report to get that fixed? I wonder whether I got something wrong here.

Am I the only one who experiences that behaviour? According to
http://www.google.com/search?q=msxml...tor-or-self%22 I am not.
In that case, why has this not been fixed yet? That''s not just a cosmetic
disorder. I found a similar bug report confirmed and apparently fixed (?) by
Microsoft for MSXML Core Services 4.0 (MSXML 3.0).

I am running VS 2005 + .NET 2.0 (MSXML 6.0) on XP Pro SP2 having all
updates, patches, fixes and that stuff. Is it possible that a recent update
revived the old bug?

- Does anyone know whether MS has yet confirmed this one?
- Has anyone else experienced these effects, though this problem may not be
recognized in all cases?
- Which work-arounds are possible?

Thanks in advance,
Matt

推荐答案

* Matthias Truxa在microsoft.public中写道。 dotnet.xml：

* Matthias Truxa wrote in microsoft.public.dotnet.xml:

> http://www.w3.org/TR/2005/CR-xpath20...th-ReverseAxis

请注意，这是一个过时的XPath 2.0草案，目前唯一的相关规范是< http：//www.w3.org/TR/xpathunless你是

使用声称支持XPath 2.0的产品。

Note that this is an outdated draft of XPath 2.0, at the moment the only
relevant specification is <http://www.w3.org/TR/xpathunless you are
using a product that claims support for XPath 2.0.

> Howeve r，当使用固定索引时，实现仅以正确的顺序访问这些轴。在谓词中使用轴或通过节点集循环时，轴恰好以错误的顺序排出
（评估顺序正确，节点集不是）。

>However, the implementation only accesses these axes in the right order when
using fixed indices. When using the axis in a predicate or when cycling
through a nodeset instead, the axis happens to be put out in the wrong order
(evaluation order is correct, nodeset population is not).

节点集没有订单（它们是集合，而不是序列），更重要的是，
重要的是.SelectNodes方法取决于微软，

XPath规范没有定义此方法的语义。所以不，

这不是一个错误。

-

Bj？rn H？hrmann·mailto：bj **** @ hoehrmann.de· http://bjoern.hoehrmann.de

Weinh。海峡。 22·Telefon：[phone]· http://www.bjoernsworld.de

68309曼海姆·PGP Pub。 KeyID：0xA4357E78· http://www.websitedev.de/

Node-sets do not have an order (they are sets, not sequences) and, more
importantly, what the .SelectNodes method does is up to Microsoft, the
XPath specification does not define the semantics of this method. So no,
this is not a bug.
--
Bj?rn H?hrmann · mailto:bj****@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: [phone] · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Hallo Bj？


thanx您的快速回答和规格更新，但在那里我们仍然

具有相同的陈述：


轴是正轴或反轴。只有
的轴包含上下文节点或位于

文档顺序中的上下文节点之后的节点是前向轴。只包含

上下文节点的轴或文档顺序中上下文节点之前的节点是反向轴的b / b
。因此，祖先，祖先或自我，前面和前面的兄弟轴是反向轴;所有其他轴都是前轴。

[...]

Hallo Bj?rn,

thanx for your fast answer and for the spec update, but in there we still
have the same statement:

"An axis is either a forward axis or a reverse axis. An axis that only ever
contains the context node or nodes that are after the context node in
document order is a forward axis. An axis that only ever contains the
context node or nodes that are before the context node in document order is
a reverse axis. Thus, the ancestor, ancestor-or-self, preceding, and
preceding-sibling axes are reverse axes; all other axes are forward axes.
[...]

>>>节点集成员相对于
轴的接近位置被定义为按顺序排列的节点集中节点的位置
如果轴是正轴并且反向排序
文档顺序，如果轴是反向轴。 <<<<第一个位置
是1.

>>>The proximity position of a member of a node-set with respect to an
axis is defined to be the position of the node in the node-set ordered
in document order if the axis is a forward axis and ordered in reverse
document order if the axis is a reverse axis. <<<< The first position
is 1.

谓词过滤相对于轴的节点集以生成新的

node-set。对于要过滤的节点集中的每个节点，使用该节点作为上下文节点评估PredicateExpr

，节点集中的节点数为
作为上下文大小，并且节点集中的

节点相对于轴的接近位置作为上下文位置;如果

PredicateExpr对该节点的计算结果为true，则该节点包含在

新节点集中;否则，它不包括在内。

A predicate filters a node-set with respect to an axis to produce a new
node-set. For each node in the node-set to be filtered, the PredicateExpr is
evaluated with that node as the context node, with the number of nodes in
the node-set as the context size, and with the proximity position of the
node in the node-set with respect to the axis as the context position; if
PredicateExpr evaluates to true for that node, the node is included in the
new node-set; otherwise, it is not included."

节点集没有订单（它们是集合，而不是序列），更多

重要的是，.SelectNodes方法的功能取决于Microsoft，

XPath规范没有定义此方法的语义。所以不，

这不是一个bug。

Node-sets do not have an order (they are sets, not sequences) and, more
importantly, what the .SelectNodes method does is up to Microsoft, the
XPath specification does not define the semantics of this method. So no,
this is not a bug.

如果每个实现都可以自由决定，那根本就没有意义。

这会导致混乱的行为无法评估

或至少正确填充文档。在上面的文字中，它清楚地说明了

表示该集合按照文件中节点的出现顺序填充，相对于轴的方向顺序。


如何为给定的案例编写解决方案（）？


另外，为什么要考虑同样的问题成为一个bug？

同时，我还发现了一个错误修正：
http://support.microsoft.com/default...;EN-US;q291193 ，但这个

从2002年开始，用于MSXML 3.0：


症状

使用XPath反向轴指定节点列表时，您会发现

节点列表的方向不会反转。 XPath反向轴包括

祖先，祖先或自我，前置和前置兄弟。


状态

Microsoft已确认这是本文开头列出的Microsoft产品

中的一个问题。


此错误已在Microsoft XML 3.0 Service中得到纠正包装1.


嗯 - 我想报告 - 它没有。

Besten Gruss，

Matt

That wouldn''t make sense at all, if each implementation could freely decide.
This would result in chaotic behaviour and one would not be able to evaluate
or at least populate a document correctly. In the text above, it clearly
states that the set is populated in the order of appearance of the nodes in
the document, with respect to the direction order of the axis.

How am I supposed to program a solution for the given case ()??

Also, why has the very same problem considered to BE a bug once?
Meanwhile, I also found a bugfix:
http://support.microsoft.com/default...;EN-US;q291193, but this
from 2002 and for MSXML 3.0:

SYMPTOMS
When you use an XPath reverse axis to specify a nodelist, you find that the
direction of the nodelist is not reversed. The XPath reverse axes include
ancestor, ancestor-or-self, preceding, and preceding-sibling.

STATUS
Microsoft has confirmed that this is a problem in the Microsoft products
that are listed at the beginning of this article.

This bug was corrected in Microsoft XML 3.0 Service Pack 1.

Well - as I''d like to report - it has NOT.
Besten Gruss,
Matt

重要的是，.SelectNodes方法的作用取决于微软，

importantly, what the .SelectNodes method does is up to Microsoft, the

XPath规范没有定义这种方法的语义。所以不，

这不是一个bug。

XPath specification does not define the semantics of this method. So no,
this is not a bug.

如果它只是SelectNodes方法我不会遵守（这也应该是

也是一个有序的集合）。顺便说一句，一个集合是一个数学小组（DE：

Menge / Reihe / Gruppe）因此而是一个序列比一些

表或抛出的碎片。


但即使在如下的谓词中，订单也完全颠倒了：


返回thirdElement.SelectSingleNode（" ancestor-or-self： ：* [string（myattrib）

！=''''''）。）。值


spec规定节点测试导航必须是第三个，第二，第一，

root，没有反转。

If it only were the SelectNodes method I wouldn''t comply (also this should
be an ordered set too). By the way, a set is a mathematical group (DE:
Menge/Reihe/Gruppe) and therefore rather a sequence with order than some
table or thrown together pieces.

But even in predicates like the following, the order purely reverses:

return thirdElement.SelectSingleNode("ancestor-or-self::*[string(myattrib)
!= '''']").Value

spec states that the node test navigation must be third, second, first,
root, not reversed.

这篇关于msxml中的错误？要求确认。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！