Cant assume Saxon script found is from EXPath

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Run the 0.4.0rc1 on Fedora Core 16

What do you see instead?
Creating Test Stylesheet...
Command line option -x requires a value

What version of the product are you using? On what operating system?
0.4.0rc1 on Fedora Core 16 AMD64

Please provide any additional information below.
The problem is at line 56 of the xspec.sh script. You cannot assume that if you 
find an executable called 'saxon' then it is from the EXPath project. In the 
case of Fedora 16, there is a 'saxon' executable installed in /usr/bin which is 
Saxon8 and is installed by YUM as a system package.

Cheers Adam.

Original issue reported on code.google.com by adam.ret...@googlemail.com on 14 May 2012 at 11:25

[GoogleCodeExporter]

True.  I am not sure how to solve this problem though.  We could call "saxon 
--help" and see whether it is the EXPath script or not.  If it is that's ok, 
but if it's not, there's a risk we launch Java (and actually run the Saxon main 
class) just to test that, before actually calling Saxon for the transform.  
Sounds like a bit expensive.

What about a script variable that one can switch on or off by editing the 
script by hand?  I'm not a fan of editing the script by hand, but I'm not sure 
we have the choice here...

What do you think?

Thanks for the bug report!

Original comment by fgeorges on 14 May 2012 at 2:03

• Changed state: Accepted
• Added labels: Milestone-Release0.4

[GoogleCodeExporter]

I think you shouldnt have to Edit the script by hand. Simply XSpec should not 
have a direct dependency on EXPath. I would probably add a flag to the command 
line arguments for xspec.sh so that you can specify an EXPath installation path 
(if you have it installed)

e.g. xspec.sh --with-expath=/path/to/expath.

Original comment by adam.ret...@googlemail.com on 14 May 2012 at 5:30

[GoogleCodeExporter]

I agree editing the script by hand is not ideal.  But providing it via an 
option is not neither.  This is really an install-time property (that has to be 
set once for ever) rather than a run-time property (that has to be provided 
every time on the command line).

If there are several existing scripts to call Saxon (on different systems), the 
user will have anyway to tell one way or another which one to use at 
install-time.  What's the interface of /usr/bin/saxon from YUM?

Original comment by fgeorges on 14 May 2012 at 5:58

[GoogleCodeExporter]

Im sorry I disagree. XSpec is not part of EXPath, so very simply it should not 
have a direct dependency on it. Yes EXPath is great, but not everyone uses it, 
I suspect there are many more XSpec users than EXPath users ;-)

I think a cmd line arg for the optional EXPath support is perfect, and that if 
people want that every time they can simply alias the cmd with the arg. If this 
is properly documented then it is not an issue for anyone.

It is a worse user experience if it doesnt work out of the box, and people have 
to mess around with XSpec to get it working in its normal vanilla mode (e.g. 
without EXPath).

BTW - I also think that you should just ship the Saxon-PE Jar with EXPath, as 
getting that setup is also a pain, I have had to configure 3 peoples machines 
today that are trying to learn XSpec because they are beginners and couldnt 
figure it out.

Original comment by adam.ret...@googlemail.com on 14 May 2012 at 7:23