I've got a custom XPathNavigator that encapsulates a stream. I'm using
xpath expressions to seek forward to various positions within the stream.
Using a limited set of xpaths, I can get my stream to move forward only (no
backward seeks). This works fine until a filter expression is introduced,
at which point the entire stream is read before the first selection is
returned. I've traced the problem to the System.Xml.XPath.MergeFilterQuery
class, who's implementation of advance() makes a list of all matches in the
document before returning the first one. I can clearly see that this method
could have been coded differently, so that each call would have cursored
forward to the next match. This would be more consistent with the behaviour
of the other IQuery implementations.

To illustrate how strange this is, consider the following long xml document:

<list>
<item/>
<item/>
<!-- a million more item elements here -->
</list>

If I select on the xpath expression "/list/item[1]", MergeFilterQuery will
check all one millon item elements against the filter expression "[1]"
before returning the first one!

Now I'm faced with having to throw out the entire dotnet xpath selection
mechanism in favour of coding it myself or modifying Rotor, all due to the
implementation decisions in an internal sealed class! Does anyone have any
suggestions on how I might override this behaviour? Is there any way to
have this issue looked at for dotnet 2.0?

Steve Taylor

[quoted text, click to view]

Take a look at XPathReader project:
http://msdn.microsoft.com/XML/default.aspx?pull=/library/en-us/dnexxml/html/xml05192004.asp
http://workspaces.gotdotnet.com/xpathreader
--
Oleg Tkachenko [XML MVP]