Saxon

Are you sure the two files demonstrate the issue?

I wrote

            string xmlUri = "https://saxonica.plan.io/attachments/download/49089/input.xml";
            string xsltUri = "https://saxonica.plan.io/attachments/download/49088/transform.xsl";

            Processor processor = new Processor();

            Console.WriteLine("{0}: {1}", processor.ProductTitle, processor.ProductVersion);

            XsltCompiler compiler = processor.NewXsltCompiler();

            Xslt30Transformer xslt30Transformer = compiler.Compile(new Uri(xsltUri)).Load30();

            DocumentBuilder docBuilder = processor.NewDocumentBuilder();

            var input = docBuilder.Build(new Uri(xmlUri));

            xslt30Transformer.GlobalContextItem = input;

            xslt30Transformer.ApplyTemplates(input, processor.NewSerializer(Console.Out));

with .NET and using the version of Saxon you use and get

SAXON-HE 9.9.1.5N from Saxonica: 9.9.1.5
0
1
0

I confirmed that the files do have the issue for me. However, by you including your code, I was able to see where the difference is between your results and mine. I ran your code as-is, and also got 0 1 0 for results. Then I adjusted it to look more like my code, until the results switched to 3 3 0. The key difference turned out to be the way that I'm supplying the input:

Dim myInputDoc As New Xml.XmlDocument Dim myFileStream As FileStream = New FileStream(xmlUri,FileMode.Open,FileAccess.Read, FileShare.ReadWrite) Dim mByte() As Byte ReDim mByte(CInt(myFileStream.Length) - 1) myFileStream.Read(mByte, 0, CInt(myFileStream.Length)) myFileStream.Close() Dim myMemStream As MemoryStream = New MemoryStream(mByte) myInputDoc.Load(myMemStream) xslt30Transformer.ApplyTemplates(docBuilder.Wrap(myInputDoc), processor.NewSerializer(Console.Out))

When I load the input this way, I get 3 3 0 for results.

That might be a bug then in https://dev.saxonica.com/repos/archive/opensource/latest9.9/hej/net/sf/saxon/dotnet/DotNetNodeWrapper.java or at least in the code behind the Wrap method.

It seems that, with a wrapped XmlDocument, for the empty p elements, the XPath descendant::sectPr finds all descendant sectPr elements of the following sibling p elements instead of (simply?) returning an empty sequence.

A more simple test case is

<?xml version="1.0" encoding="utf-8" ?>
<root>
  <item/>
  <item>
    <foo id="foo1"/>
  </item>
  <item></item>
  <item>
    <foo id="foo2"/>
  </item>
</root>

running

<?xml version="1.0" encoding="utf-8"?>
<xsl:transform version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="#all">

  <xsl:param name="DEBUG" static="yes" as="xs:boolean" select="true()"/>

  <xsl:output method="text" item-separator="&#10;"/>

  <xsl:template match="/">
    <xsl:for-each select="//item">
      <xsl:assert test="not(*) eq not(descendant::foo)" use-when="$DEBUG">No child elements but descendants</xsl:assert>
      <xsl:value-of select="position(), not(*), descendant::foo/@id"/>
    </xsl:for-each>
  </xsl:template>

</xsl:transform>

gives

1 true
2 false foo1
3 true
4 false foo2

for Saxon's Xdm but

1 true foo1 foo2
2 false foo1
3 true foo2
4 false foo2

for a wrapped .NET XmlDocument.

I wrote a unit test for the example in comment #5 which shows that we are getting it right with the Java DOM, which uses almost identical code.

For the Java DOM, the method DOMNodeWrapper.getSuccessorNode() has the following test:

        if (anchor != null && start.isSameNode(anchor)) {
            return null;
        }

which is missing from the corresponding method for the .NET DOM, DotNetNodeWrapper.getSuccessorNode(). I suspect these lines need to be added - but we need to test this on .NET. The test ensures that if we are positioned at the "anchor" node (the one whose descendants we are seeking), we return "end of sequence" rather than moving on to the next following sibling,

These lines were added to DOMNodeWrapper on 2013-04-07 (revision 2272): no bug number was recorded. It appears this revision fixed bugs in all the third-party tree models using the SteppingNode framework (which was introduced in 2012-09) with the exception of the .NET DOM code. So it looks like the bug has gone undetected for quite a while.

It's probably safe with the C# DOM to compare DOM nodes for identity using the "==" operator, that is to assume that node identity implies object identity. This isn't a safe assumption with the Java DOM, since nodes can be instantiated lazily.

Or use https://docs.microsoft.com/en-us/dotnet/api/system.object.referenceequals?view=netframework-4.6 as that always compares object identity while == might have been overridden (although it doesn't seem to be the case in the XmlNode/XmlDocument classes).

Yes I had thought I could use == operator. The DOM spec description is clear on what to expect from the isSameNode method.

Also looking at the Xerces implementation on Java it see to have the same implementation:

    public boolean isSameNode(Node other) {
        // we do not use any wrapper so the answer is obvious
        return this == other;
    }

Added a nunit test case for testing of this bug for regression purposes. Looking at the W3C test suites for better testing when have a C# DOM node as the tree model within Saxon.

Added QT3 test case prod-AxisStep/K2-Axes-106