Issue 49 in xspec: Cant assume Saxon script found is from EXPath

[xs...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 49 by adam.ret...@gmail.com: Cant assume Saxon script found is
from EXPath
http://code.google.com/p/xspec/issues/detail?id=49

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.

[xs...@googlecode.com]

Updates:
Status: Accepted
Owner: fgeor...@gmail.com
Labels: Milestone-Release0.4

Comment #1 on issue 49 by fgeor...@gmail.com: Cant assume Saxon script

found is from EXPath
http://code.google.com/p/xspec/issues/detail?id=49

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!

[xs...@googlecode.com]

Comment #2 on issue 49 by adam.ret...@gmail.com: Cant assume Saxon script

found is from EXPath
http://code.google.com/p/xspec/issues/detail?id=49

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.

[xs...@googlecode.com]

Comment #3 on issue 49 by fgeor...@gmail.com: Cant assume Saxon script

found is from EXPath
http://code.google.com/p/xspec/issues/detail?id=49

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?

[xs...@googlecode.com]

Comment #4 on issue 49 by adam.ret...@gmail.com: Cant assume Saxon script

found is from EXPath
http://code.google.com/p/xspec/issues/detail?id=49

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.