Xalan uncomfortable reading XSL as input document? Let usage message point to specific problem?

[Jan Schormann <Ja...@BrainLAB.com>]

Hi all,

there's something I believe is meant as a helpful feature,
but I'm wondering whether it gets in the way sometimes.

Note: This message doesn't exactly call for action on
anyone's part, and I'm not presenting a patch either,
naughty me. I hope this can help just by being in the
archives, as I didn't find anything there when I looked.
(If I've overlooked anything: Sorry for the noise.)

See what happens when I try to *process* an XSL file,
using *itself*:

  $ xalan testXslproc.xsl testXslproc.xsl
  Xalan version 1.8.0.
  Xerces version 2.5.0.
  Usage: Xalan [options] source stylesheet
  Options:
    -a                    Use xml-stylesheet PI, not the
'stylesheet' argument
    -e encoding           Force the specified encoding for the
output.
    -i integer            Indent the specified amount.
    -m                    Omit the META tag in HTML output.
    -o filename           Write output to the specified file.
    -p name expression    Sets a stylesheet parameter.
    -t                    Display timing information.
    -u                    Disable escaping of URLs in HTML output.
    -?                    Display this message.
    -v                    Validates source documents.
    -                     A dash as the 'source' argument reads from
stdin.
                          ('-' cannot be used for both arguments.)

So what exactly is wrong here?

Curious as I am, I tried many things. Eventually, I hard-linked
the "testXslproc.xsl" to "...1.xsl", et voilà, the positive
response I had expected:

  $ xalan testXslproc.xsl testXslproc1.xsl
  XSLT Message: OK.Source tree node: xsl:stylesheet.
    (file:///F:/braintools/contrib/xsl/testXslproc1.xslLine 6,
column 18.)

What I learned from the experiment is this:

 - Basically, Xalan 1.8 has no problems processing XSL as input
   documents (shouldn't, it's only XML), and is even happy
   using the *same* file as XSL and input if only they have
   different names, but ...

 - Looking into the source, there is this specific test in
   line 446 of XalanExe.cpp:

	else if (strcmp(params.m_xslFileName, params.m_inFileName) == 0)
	{
		return false;
	}

I was initially confused by Xalan's response, because the
message doesn't really give me a hint towards the problem,
even though the "error" on my side seems quite specific.

There doesn't seem to be support for specific responses
to any error in the command line setup, so I'd rather not
present a patch right now, as it would change quite a lot
in a file that I'm not familiar with.

Of course, this use is quite over the edge. In case you're
wondering:

<OT>
I'm using this little XSL to check whether a certain XSL
processor runs on one of our workstations. I'm using instant
saxon, java saxon, "instant" xt from 1999 and java xt from
2002, and Xalan-C++ interchangeably on the machines. I'm
preferring Xalan-C++ for future development, but we've got
some legacy crap that I'd rather not touch right now. Only
I have to touch it, because "instant" xt seized to work on
a recent XP installation, even with the old MS-JVM dropped
on top.

And that's exactly why I like to have this test work: I'll
be switching a set of tools that call the old xt to using
Xalan-C++ 1.8 instead and I'll have to double-check that
I'm not breaking anything for my users.

Using the XSL as input at the same time is an arguably
short-sighted means of saving space ... So I'll start
using an extra XML file to make Xalan happy,
</OT>

.. though I don't quite see the benefit of that check on
the filenames. If it's meant to be helpful, IMHO it should
produce a specific message, otherwise I'd rather let it
run with these arguments, because I figure a greater chance
that unexpected output can point me in the right direction
*iff* I accidentally got the parameters mixed up.

Anyone agree?

Are more specific usage hints on the todo-list already?

Should I dive into it and produce a patch,
 - providing a means or pattern for specific
   error messages, or
 - removing the check in case no-one would be
   missing it?

Frankly, I'll consider this after getting really
positive responses - otherwise I'd rather live with
the current state, seeing it as a minor usability issue,
and hoping that this elaboration may help others.

Honestly, I HTH!
Jan.