Saxon » SaxonJS

The raw result of the transformation consists of a parentless element node (which at the implementation level actually belongs to a DocumentFragment), followed by a parentless Comment node.

It's then up to the fn:transform() function to turn this sequence into a document tree by wrapping in a document node. The code to do this is at CoreFn#2776, and it appears to ignore everything in the sequence except element nodes and text nodes.

For some reason a call to Copy.makeComplexContent() has been commented out here.

I think the correct logic is to create a Builder, issue a startDoc(), append() each item in the raw result sequence, then issue endDoc().

I've considerably simplified the logic in fn:transform() so it now does:

            if (buildTree) {
                Diag.assert(Array.isArray(r));
                const builder = getBuilder(context);
                const out = Push.getComplexContentOutputter(builder);
                out.startDoc();
                r.forEach(it => out.append(it));
                out.endDoc();
                out.close();
                r = builder.sequence;
            }

and this test now passes. But it's a big change, so it needs careful regression testing.

In the XSLT3 test suite, the change has fixed a few outstanding test failures (e.g. in accumulator), but has also resulted in a handful of new test failures, notably in current-output-uri, message, mode, output, position, result-document, try. I will investigate these.

In QT3 we're seeing 13 failures in fn-transform and one failure in xs-numeric (which is probably induced by previous bug fixes since I last ran QT3).

Homing in on the fn:transform failures, they are failures in the line

Diag.assert(Array.isArray(r));

included in the new code above.

The existing code tries to cope with r (the raw result) being either an array or a singleton. I'd prefer to be consistent about it always being an array if possible, which is why I added the assertion.

In fn-transform-14 there is no principal result document (only secondary results), and r is null. Bypassing the tree construction if r===null I now get 11 failures in fn:transform, for example fn-transform-35.

In fn-transform-35, the request is for delivery-format:"serialized": it seems that the serialized form has been wrapped in a new doccument node and serialized again. The problem seems to be that the buildTree variable is true even though what we have is already a serialized result.

CoreFn#2694 sets let buildTree = destinationType !== "raw";. Changing that so we don't set buildTree if the destination is "serialized" means we now pass all the fn:transform tests.