my XSL contains a <xsl:include href="./blabla.xsl"/> which was working file using the default XSLTProc of PHP but fails here saying that /tmp/blabla.xsl" cannot be found.
Can anyone tell me what I did wrong? or how to correct this embarrassing problem please?
AF
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry I believe I was not very clear in my question. Let me try again.
I have successfully run XML_XSLT2Processor on a simple XSL.
But... I have then tried the next step. I am writing a system with a lot of similar small templates: therefore I have a file, a xsl file which I include into all my XSL with a xsl:include tag. AND this is where the problem is coming from. I am under the impression that the original XSL is copied to a temporary place and when the XSL is actually processed by SAXON it cannot resolved the relative path to my XSL library.
I probably could write an absolute path which I would prefer not as I am not testing on the production server but on my local machine which does not have the same path construction...
Is my problem more understandable?
Thank you for any suggestions you might have.
PS I tried calling my SAXON processor on the command line and could apply my transform correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
v0.4.2 is the only version which had this problem, but it's been fixed long ago.
Try to specify the path to the XSLT as a string to importStylesheet(), i.e.
$proc->importStylesheet('stylefoo.xsl');
I'm assuming there may be something wrong in the way XML_XSLT2Processor handles DOMDocument objects, but I'm not sure what... when paths are supplied as strings, the absolute path to the XSLT is given to SAXON, and from then on, it's SAXON's turn to resolve the paths (and it should resolve them relative to the location of the main XSLT file).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Which is going to cause problems when imports are used, which I'm using heavily.
I'm not sure why this is done, since I can't see any advantage of doing it this way over accessing the files directly and just storing the result in a tmp file. (I tested running that command and replacing the files with the correct locations and it worked fine and produced the correct output in the /tmp folder).
Is there a way to disable to usage of temp files? or would this be possible to add?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the debugging info. Now I see the problem is that for some reason, Linux creates the temporary files in the temporary folder instead of the original file's folder. I'll see what I can do to fix this.
In the meantime, there are three things you may try:
1. As I already suggested, pass the input as a string. This will NOT create a temporary file for the XSLT.
2. In your XSLT, add xml:base attribute pointing to your XSLT's real location. SAXON will resolve paths based on that location, regardless of how you passed the document to it.
3. Use version 0.4.2 until I prepare a fix (back before I meant version *prior* to it had this problem). In 0.4.2, there's absolutely no difference between DOMDocument inputs and string inputs.
Anyway, when you use DOMDocument objects, temporary files are necessary. Without them, you won't be able to do modifications of your source documents (input and stylesheet alike).
For example, you may want to do:
$dom = new DOMDocument;
$dom->load('stylefoo.xsl');
$dom->documentElement->setAttribute('id','MyOwnValue');
which won't work like expected if only the URI of the document was used (as in 0.4.2). You'll instead get the original document, not the document, as after modifications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am trying to use XML_XSLT2Processor with a saxon9 under java running on a Linux system and I am encountering problems with a very simple case:
<?php
include "XML/XSLT2Processor.php";
$doc = new DOMDocument();
$xslt2 = new XML_XSLT2Processor('SAXON',null,'JAVA-CLI');
$doc->load("./presence/parseSearchProductRS.xsl");
$xslt2->importStyleSheet($doc);
$doc->load("./output/providerRS.xml");
echo "parsing output/providerRS.xml <br/>";
$res = $xslt2->transformToXML($doc);
if(!$res) $res = XML_XSLT2Processor::getErrors(-1)->message;
echo '<textarea rows="20" cols="100">'.$res."</textarea>";
echo "<br/> Terminé </br>";
?>
my XSL contains a <xsl:include href="./blabla.xsl"/> which was working file using the default XSLTProc of PHP but fails here saying that /tmp/blabla.xsl" cannot be found.
Can anyone tell me what I did wrong? or how to correct this embarrassing problem please?
AF
It's hard to say exactly what's going on with your problem going by what you said, but echoing your $res might give you a better idea.
Here's a known good (works for me at least) example:
<html>
<?php
include "XML/XSLT2Processor.php";
XML_XSLT2Processor::clearErrors ();
$xml = 'indexfoo.xml';
$xsl = 'stylefoo.xsl';
$proc = new XML_XSLT2Processor('SAXON', 'file:////usr/java/jdk1.5.0_14/bin/java_exec');
$proc->importStyleSheet($xsl); // attach the xsl rules
if ($html = $proc->transformToXML($xml)) {
print $html;
} else {
print_r(XML_XSLT2Processor::getErrors());
//echo $proc->command;
}
?>
</html>
Sorry I believe I was not very clear in my question. Let me try again.
I have successfully run XML_XSLT2Processor on a simple XSL.
But... I have then tried the next step. I am writing a system with a lot of similar small templates: therefore I have a file, a xsl file which I include into all my XSL with a xsl:include tag. AND this is where the problem is coming from. I am under the impression that the original XSL is copied to a temporary place and when the XSL is actually processed by SAXON it cannot resolved the relative path to my XSL library.
I probably could write an absolute path which I would prefer not as I am not testing on the production server but on my local machine which does not have the same path construction...
Is my problem more understandable?
Thank you for any suggestions you might have.
PS I tried calling my SAXON processor on the command line and could apply my transform correctly.
v0.4.2 is the only version which had this problem, but it's been fixed long ago.
Try to specify the path to the XSLT as a string to importStylesheet(), i.e.
$proc->importStylesheet('stylefoo.xsl');
I'm assuming there may be something wrong in the way XML_XSLT2Processor handles DOMDocument objects, but I'm not sure what... when paths are supplied as strings, the absolute path to the XSLT is given to SAXON, and from then on, it's SAXON's turn to resolve the paths (and it should resolve them relative to the location of the main XSLT file).
I'm getting this too.
Looking into it it seems that the command that's run is something like this...
java -jar '/include/saxon/saxon9.jar' -o:/tmp/RESULT_TEMP6bxiYY -s:/tmp/XML_TEMPKcIdJA -xsl:/tmp/XSL_TEMPMI6FsL
Which is going to cause problems when imports are used, which I'm using heavily.
I'm not sure why this is done, since I can't see any advantage of doing it this way over accessing the files directly and just storing the result in a tmp file. (I tested running that command and replacing the files with the correct locations and it worked fine and produced the correct output in the /tmp folder).
Is there a way to disable to usage of temp files? or would this be possible to add?
Thanks for the debugging info. Now I see the problem is that for some reason, Linux creates the temporary files in the temporary folder instead of the original file's folder. I'll see what I can do to fix this.
In the meantime, there are three things you may try:
1. As I already suggested, pass the input as a string. This will NOT create a temporary file for the XSLT.
2. In your XSLT, add xml:base attribute pointing to your XSLT's real location. SAXON will resolve paths based on that location, regardless of how you passed the document to it.
3. Use version 0.4.2 until I prepare a fix (back before I meant version *prior* to it had this problem). In 0.4.2, there's absolutely no difference between DOMDocument inputs and string inputs.
Anyway, when you use DOMDocument objects, temporary files are necessary. Without them, you won't be able to do modifications of your source documents (input and stylesheet alike).
For example, you may want to do:
$dom = new DOMDocument;
$dom->load('stylefoo.xsl');
$dom->documentElement->setAttribute('id','MyOwnValue');
which won't work like expected if only the URI of the document was used (as in 0.4.2). You'll instead get the original document, not the document, as after modifications.