Saxon

Legacy ID: #7538346 Legacy Poster: Lea Hayes (numberkruncher)

The "xptr:scheme" elements are created dynamically in a temporary tree. I have just tried adding a document-node to the root of this tree and the "saxon:evaluate-node" function appears to be working fine now. Without the document-node, the results seem a little inconsistent because sometimes "evaluate-node" was producing the expected outcome, and other times not. Is having a "document-node" a requirement of the "saxon:evaluate-node" function?

Legacy ID: #7541266 Legacy Poster: Michael Kay (mhkay)

The most likely explanation of this is that the base URI of the node at $current-scheme is unknown. Arguably since you supplied an absolute URI to the document() function, it shouldn't matter that the base URI is unknown, but it often does. I'm not sure why the base URI should be unknown, but the rules for establishing the base URI of a temporary tree are quite complicated and the internal code even more so. It would be useful to have a complete stylesheet that reproduces the problem.

Legacy ID: #7541273 Legacy Poster: Michael Kay (mhkay)

I haven't been able to reproduce the problem. Are you perhaps running the transformation such a way that the base URI of the stylesheet is unknown (e.g. supplying the stylesheet as a StreamSource with no systemId)?

Legacy ID: #7541722 Legacy Poster: Lea Hayes (numberkruncher)

I am pretty sure that the systemId is being specified correctly for both the XML and XSL StreamSources. This was the source of a different problem which you assisted me with previously. // Set base-uri of stylesheet resource. xslSource.setSystemId(xslBaseURI.toString()); // Set base-uri of XML resource. xmlSource.setSystemId(xmlURI.toString()); I can send you a version of the XPointer XSLT source (where "saxon:evaluate-node" is being used). But, in most situations it seems to work fine. Simply wrapping the temporary tree within a <xsl:document> node immediately solves the problem (this is inside the XPointer stylesheet). I have a fairly large selection of stylesheets which are making use of the XPointer stylesheet. I am trying to put together a simple stylesheet which exposes this problem, but this is turning out to be more difficult than I had anticipated. I will give this another try when I get home from work later tonight.

Legacy ID: #7542087 Legacy Poster: Lea Hayes (numberkruncher)

I have narrowed the problem down within the larger system. I have reduced the stylesheets to the bare minimum required to reproduce the error. For this reason the actual stylesheets presented here do not make a lot of sense. There seems to be some sort of internal corruption happening within Saxon because just swapping two lines within the XSL stylesheet toggles the error on/off. Alternatively, adding <xsl:document> around the element that is used with the "saxon:evaluate-node()" call, also fixes the problem. (Line 290 of "xptr.xsl") The problem only appears to occur from the context of the Java API, I cannot get <oxygen/> to reproduce the same problem. I hope that this helps a little. File Listings: xptr.xsl: ========= Available from: http://www.rotorz.net/xml/2009/XPointer/downloads/XptrXslt2_RC1.zip Documentation: http://www.rotorz.net/xml/2009/XPointer/downloads/spec_RC1.pdf BSD License: http://www.rotorz.net/xml/2009/XPointer/license.html (Note: The above links point to a pre-release version of "XPointer Framework for XSLT 2.0".) input.xml: ========== <?xml version="1.0" encoding="UTF-8"?> <test> The Input File! </test> test.xml: ========= <?xml version="1.0" encoding="UTF-8"?> <test> Hello World! </test> broken.xsl: =========== <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xptr="http://www.rotorz.net/xml/2009/XPointer" exclude-result-prefixes="xs xptr"> <xsl:import href="xptr.xsl"/> <!-- This version does NOT work: --> <xsl:template match="/"> <xsl:variable name="phase1" as="element()"> <outline xml:base="{base-uri(.)}"/> </xsl:variable> <outline xml:base="{$phase1/@xml:base}"/> <!-- Simply lookup and copy root element of "test.xml". --> <xsl:copy-of select="xptr:lookup(.,'test.xml#element(/1)')"/> </xsl:template> </xsl:stylesheet> works.xsl: ========== <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xptr="http://www.rotorz.net/xml/2009/XPointer" exclude-result-prefixes="xs xptr"> <xsl:import href="xptr.xsl"/> <!-- This version DOES work: --> <xsl:template match="/"> <xsl:variable name="phase1" as="element()"> <outline xml:base="{base-uri(.)}"/> </xsl:variable> <!-- Simply lookup and copy root element of "test.xml". --> <xsl:copy-of select="xptr:lookup(.,'test.xml#element(/1)')"/> <outline xml:base="{$phase1/@xml:base}"/> </xsl:template> </xsl:stylesheet>

Legacy ID: #7545783 Legacy Poster: Michael Kay (mhkay)

Your example is working for me. (It gets the base URI right, and outputs the content of test.xml). Could you please: (a) confirm that you are using Saxon 9.1.0.7 (b) say more precisely how you are running the example (e.g., what is the directory structure, and how do you invoke the transformation). You say you only get the problem when running from the Java API, so the most likely explanation is that you are invoking Saxon incorrectly - but as far as I can see you haven't shown your Java code. (c) indicate what output you get

Legacy ID: #7546791 Legacy Poster: Lea Hayes (numberkruncher)

(a) confirm that you are using Saxon 9.1.0.7 Yes, that is correct. (b) say more precisely how you are running the example (e.g., what is the directory structure, and how do you invoke the transformation). You say you only get the problem when running from the Java API, so the most likely explanation is that you are invoking Saxon incorrectly - but as far as I can see you haven't shown your Java code. I have put together a simple test application in Java which exposes the problem. The program runs two tests (from scratch). One to demonstrate the working version, and another to demonstrate the broken version. The source requires that the contents of the ZIP file is extracted to: "C:\MikeTest&quot;. The ZIP contains all of the relevant XML and XSL files. I have changed the files slightly to ease the test program. Available From: http://www.rotorz.net/xml/2009/XPointer/downloads/MikeTest.zip Please could you indicate when you have finished with this file so that I can remove it from the web server. (c) indicate what output you get The above program gives the following output on my system: Testing: Working Version: ========================= Initializing... Loading source document... Transforming document... <?xml version="1.0" encoding="UTF-8"?><output-root><test> Hello World! </test><outline xml:base="file:/C:/MikeTest/xml/works.xml"/></output-root> Success. Testing: Broken Version: ======================== Initializing... Loading source document... Transforming document... Recoverable error on line 1 FODC0002: Exception thrown by URIResolver Error on line 1 FODC0005: Failed to load document file:/C:/MikeTest/xml/test.xml at xptr:lookup() (file:/C:/MikeTest/xsl/main.xsl#39) in built-in template rule Failed to transform document: Failed to load document file:/C:/MikeTest/xml/test.xml I really hope that this error is in my program. I just cannot understand why the program works just by swapping two lines around.

Legacy ID: #7548474 Legacy Poster: Michael Kay (mhkay)

I've downloaded the file. I can't promise to look at it immediately because I'm still finishing all the activities associated with releasing Saxon 9.2, and it's Balisage next week...

Legacy ID: #7552428 Legacy Poster: Michael Kay (mhkay)

This is proving a tough one to crack, so I'll give you an interim progress report. The doc() function is failing because although the document at the supplied URI exists (and has already been preloaded by the call to doc-available), the static base URI for the call on doc() is not a valid URI. Specifically, the value of the static base URI is the string "{base-uri()}", which is invalid because it contains curly braces. Now, when you write <outline xml:base="{base-uri()}"/> in the stylesheet, the <outline> element in the stylesheet gets a base URI of "{base-uri()}", because of course the XML parser when parsing the stylesheet does not know that this is an AVT. This is an error in your code: you shouldn't be setting xml:base to an invalid URI. What I can't see at all at the moment is why this should cause the stylesheet to fail in the way it does.

Legacy ID: #7552620 Legacy Poster: Michael Kay (mhkay)

OK, progress of a kind. When Saxon creates a temporary parentless element node it tries to reuse the tree builder that was used most recently, to save the cost of creating a new one. When it does so, the base URI initialized for that tree builder is being used (incorrectly) without checking that it is the right base URI for the new element. So when the xptr:locator-context element is created, it is getting the same base URI as the most recently created temporary element node, which was the outline element, the one that has the illegal base URI "{base-uri(.)}", when its base URI should be that of the xptr.xsl stylesheet module. Unfortunately the code for setting base URI of constructed nodes in Saxon is rather fragile, so it's difficult to make changes here without a risk of breaking something: as a result, the patch will need rather thorough testing. So don't expect it immediately. I'll raise the bug entry though.

Legacy ID: #7552700 Legacy Poster: Lea Hayes (numberkruncher)

> Now, when you write <outline xml:base="{base-uri()}"/> in the stylesheet, the <outline> element in the stylesheet gets a base URI of "{base-uri()}", because of course the XML parser when parsing the stylesheet does not know that this is an AVT. This is an error in your code: you shouldn't be setting xml:base to an invalid URI. Thanks for pointing that out, it had not occurred to me that you cannot use an AVT for the "xml:base" attribute in a stylesheet. Now that you have pointed this out, it makes complete sense. I have just tried changing all four occurrences of the misused "xml:base" attribute within the test project that I sent you, and now both tests report success. Thanks again for your help, it is very much appreciated. Have fun at Balisage!