I'm trying to install XML_XSLT2Processor and am having problems. Since we already use Altova's XMLSpy, we decided to use AltovaXML for our XSLT translator. I have the COM interface installed, and it is listed in the registry of our webserver (Windows IIS). But XML_XSLT2Processor still doesn't seem to be able to find the AltovaXML.
The error I'm getting is: "Unable to automatically resolve path to XSLT processor binary in XML_XSLT2Processor::__construct()"
I'm trying to wade through the Altova site for help, but they don't seem to be very PHP friendly. Can anyone here give me a hand?
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By default, SAXON is the default XSLT processor. Furthermore, XML_XSLT2Processor will use the command line interface by default, regardless of processor, and will thus require a binary. You'll have to explictly tell it to use AltovaXML *and* to use the COM interface instead of the CLI. To do that, use the following for the constructor:
new XML_XSLT2Processor('AltovaXML', null, 'COM');
I hope that helps.
I have to say, you've made an excellent choice with AltovaXML's COM interface. It's *the* fastest way by which XSLT 2.0 can currently be used in PHP.
And BTW, Altova's manual won't help, as not only are they not PHP friendly, they aren't "directly" compatible with it to begin with. They just expose a COM interface, and that's all (PHP thankfully happens to support COM). The only thing you can find are installation instructions (and by what you're saying, I guess you got that covered) and an API documentation (which is what XML_XSLT2Processor uses behind the scenes).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for replying, I am glad you are still around!
I was able to get XML_XSLT2Processor installed using the constructor you referenced above. However, I was getting errors during the transformation.
I took the offending file and opened it with Altova's XMLSpy and used their XSL Transformation command to weed out the various errors in the xsl files. When I finally got the xml file to render as html, I then ran the files through my PHP script which uses your XML_XSLT2Processor. The transformToDoc command returns false with an error of "XSLT Error: XTDE0410: An attribute cannot be added after a child at body". I understand from elsewhere that this is a ignorable error, which I assume is what XMLSpy does since it is able to render the xml file as html.
I noticed that your code has several layers of errors (warnings, etc) in the Saxon section but not in the Altova section. Is there a way to get Altova and XML_XSLT2Processor to ignore this error and render the html anyway? Or do I need to switch to Saxon?
Thanks for your help!
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I noticed that your code has several layers of errors (warnings, etc) in
> the Saxon section but not in the Altova section. Is there a way to get
> Altova and XML_XSLT2Processor to ignore this error and render the html
> anyway? Or do I need to switch to Saxon?
I haven't seen this before... so what you're saying is AltovaXML isn't recovering from an otherwise recoverable error?!?
Hm... that explains it... I don't have any "warning" handling for AltovaXML, as they don't have warnings. I personally asked the AltovaXML developers about that to make sure. I never asked what they do on recoverable errors though. It seems they don't recover, and just spit an error... I was hoping they'd recover.
I'd suggest you try to fix the error. Not only will it make it work with AltovaXML, but it would also mean a less error prone code in general. After all, even if you switch to SAXON, you'd still get a warning.
Let me try and help you fix the error/warning - what are the XSLT and XML in question (a reduced pair that still causes the problem will be even better than your originals)? I'll test it with the latest AltovaXML, and regardless of whether I'm able to help you with the error or not, I'll suggest to Altova that they put a "recover" option of some sort, with your XSLT (or a reduced version of it) as an example of when such an option might be useful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to install XML_XSLT2Processor and am having problems. Since we already use Altova's XMLSpy, we decided to use AltovaXML for our XSLT translator. I have the COM interface installed, and it is listed in the registry of our webserver (Windows IIS). But XML_XSLT2Processor still doesn't seem to be able to find the AltovaXML.
The error I'm getting is: "Unable to automatically resolve path to XSLT processor binary in XML_XSLT2Processor::__construct()"
I'm trying to wade through the Altova site for help, but they don't seem to be very PHP friendly. Can anyone here give me a hand?
Terry
By default, SAXON is the default XSLT processor. Furthermore, XML_XSLT2Processor will use the command line interface by default, regardless of processor, and will thus require a binary. You'll have to explictly tell it to use AltovaXML *and* to use the COM interface instead of the CLI. To do that, use the following for the constructor:
new XML_XSLT2Processor('AltovaXML', null, 'COM');
I hope that helps.
I have to say, you've made an excellent choice with AltovaXML's COM interface. It's *the* fastest way by which XSLT 2.0 can currently be used in PHP.
And BTW, Altova's manual won't help, as not only are they not PHP friendly, they aren't "directly" compatible with it to begin with. They just expose a COM interface, and that's all (PHP thankfully happens to support COM). The only thing you can find are installation instructions (and by what you're saying, I guess you got that covered) and an API documentation (which is what XML_XSLT2Processor uses behind the scenes).
SourceForge just lost my entire reply while I was logging in! AArgh!
Thank you for replying, I am glad you are still around!
I was able to get XML_XSLT2Processor installed using the constructor you referenced above. However, I was getting errors during the transformation.
I took the offending file and opened it with Altova's XMLSpy and used their XSL Transformation command to weed out the various errors in the xsl files. When I finally got the xml file to render as html, I then ran the files through my PHP script which uses your XML_XSLT2Processor. The transformToDoc command returns false with an error of "XSLT Error: XTDE0410: An attribute cannot be added after a child at body". I understand from elsewhere that this is a ignorable error, which I assume is what XMLSpy does since it is able to render the xml file as html.
I noticed that your code has several layers of errors (warnings, etc) in the Saxon section but not in the Altova section. Is there a way to get Altova and XML_XSLT2Processor to ignore this error and render the html anyway? Or do I need to switch to Saxon?
Thanks for your help!
Terry
> I noticed that your code has several layers of errors (warnings, etc) in
> the Saxon section but not in the Altova section. Is there a way to get
> Altova and XML_XSLT2Processor to ignore this error and render the html
> anyway? Or do I need to switch to Saxon?
I haven't seen this before... so what you're saying is AltovaXML isn't recovering from an otherwise recoverable error?!?
Hm... that explains it... I don't have any "warning" handling for AltovaXML, as they don't have warnings. I personally asked the AltovaXML developers about that to make sure. I never asked what they do on recoverable errors though. It seems they don't recover, and just spit an error... I was hoping they'd recover.
I'd suggest you try to fix the error. Not only will it make it work with AltovaXML, but it would also mean a less error prone code in general. After all, even if you switch to SAXON, you'd still get a warning.
Let me try and help you fix the error/warning - what are the XSLT and XML in question (a reduced pair that still causes the problem will be even better than your originals)? I'll test it with the latest AltovaXML, and regardless of whether I'm able to help you with the error or not, I'll suggest to Altova that they put a "recover" option of some sort, with your XSLT (or a reduced version of it) as an example of when such an option might be useful.