more explained
- From: "Matthias Truxa" <usmail4matt_removeprefix@xxxxxxx>
- Date: Thu, 16 Nov 2006 04:56:48 +0100
Hello,
to avoid further misunderstandings, I'm posting a more explained report of
my problem.
Meanwhile I found several sources, stating or not stating that this is a
bug.
MS explains (year 2000) why every selection, even on reversed axes, is in
document order (as long as not being indexed by number), not as the spec
would say, in reversed order to remain XSLT compatibility:
http://groups.google.de/group/microsoft.public.xml.msxml-webrelease/browse_thread/thread/9bbaf5203c974d81/05ef623d54e54ff2?lnk=st&q=msxml+reverse+axis+bug&rnum=4&hl=de#05ef623d54e54ff2
MS confirms the very same thing as a bug (in 2002):
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q291193 and assures
to have it fixed with MSXML 3+.
There is no further mention of this kind of problem except here
(http://ewbi.blogs.com/develops/2004/12/net_xsltxpath_b.html) with .net.
So I'm confused, as are some other people which experienced the same prob
are.
Thing is, that the .net implementation must not behave totally different
from other implementations and especially not different to the spec.
If this order is always reversed (resp. in document order), the reversed
axes would have absolutely no sense except for direct number indexing.
"//third/preceding-sibling::*[1]" will not return the same as
"//third/(preceding-sibling::*)[1]" and also not the same as
but "//third/preceding-sibling::*[anyDynExpr]"
seems to equal "//third/(preceding-sibling::*)[anyDynExpr]"
All I wanted to know is: how am I supposed to code this case, since I cannot
figure another way except evaluating every step programatically on client
side:
<root attrib="testroot">
<first attrib="testfirst">
<second attrib="testsecond">
<third attrib="" />
</second>
<fourth />
</first>
</root>
Task: Get the element having a value in the attribute attrib.
Prefered Solution:
return thirdElement.SelectSingleNode("ancestor-or-self::*[string(@attrib) !=
'']");
Problem:
One would suppose this walks up the hierarchy from third over second over
first to root, but the reverse is the case, it always finds root in the very
first place. So there is no sense of having those axes, except for the
rather dump (staticly known) case you want to select
"ancestor-or-self::[x]", where x is a fixed number or special node position
function. For all other cases the term is taken as an array (instead of
straight-forward processing as xpathnavigator-implementations would let
assume, processed in document order, whether or not it is parenthesised or
not. I would understand, if "(ancestor-or-self::*)[string(@attrib) != '']"
returned elements in the document order and in the case without brackets it
would use the contextual direction.
Whether or not this is a bug I don't have the time left to argument. This
has already taken me hours. If noone is interested in this I won't mind.
I simply wanted to report this inadequacy in case some other folks might
suffer or noone ever recognized this behaviour but counts on the behaviour
like I'd understand it. Still I have to find some preferably efficient
solution to get what I need using the f****** .net implementation of xpath.
If I got something wrong or my english is not understandable this might be
due to the fact its nearly 5AM here in germany meantime.
Can someone from MS please state whether this behaviour is at least known /
is different to other implementations / is logical and no compromise / is a
bug or is being fixed or has already been fixed and just revived or whatever
one could do here?
Thanks in advance,
Matt
.
- References:
- bug in msxml? confirmation requested.
- From: Matthias Truxa
- bug in msxml? confirmation requested.
- Prev by Date: how to deserialize variable element/node
- Next by Date: Re: bug in msxml? confirmation requested.
- Previous by thread: Re: bug in msxml? confirmation requested.
- Next by thread: Re: bug in msxml? confirmation requested.
- Index(es):
Relevant Pages
|
