Daniel Veillard <[EMAIL PROTECTED]>:
> This will be in the next libxslt release.
Can you give us a rough timeframe? And what do you expect the release number
to be?
While we're talking command-line options, Daniel, I have a small request.
It's for a small hook in xsltproc that would address a general problem.
I have wrestled with the problem of conditionalizing sections of an
XML document (what this crowd for some inexplicable reason calls
`profiling'). My specific problem was that I need to be able to
format both web and print-book versions of the Jargon File.
Rather than some fragile ad-hoc solution, I decided to write a generic
conditionalizing preprocessor, (I had already done one of these, sgmlpre,
for sgml-tools back in 1997, but that was SGML and used a rather ugly
markup convention that won't fly in XML-land.)
My first approach was based on Jirka Kosek's profiling stylesheet,
but XSLT turns out to be the wrong tool for this job. Two problems stand
out: (1) you can't get at the DOCTYPE attributes of the input from within
XSLT, so it's not possible to psss them through transparently, and (2) you
really don't want such a preprocessor to expand character entities, because
it might not have access to the DTD.
So I dusted off the sgmlpre code and rewrote it. The result, xmlif,
is now part of Tim Waugh's xmlto distribution. It's a simple flex
hack that interprets a small set of processing instructions -- ?if?,
?elif?, ?elif?, ?fi? -- in the obvious way. Runs really fast.
Here's my tutorial example:
Preamble
Always issue this text.
Issue this text if 'condition=html' is given on the command line.
Issue this text if 'condition=pdf' or 'condition=ps'
is given on the command line.
Otherwise issue this text.
Always issue this text.
Should display only if condition is foo
Should display only if condition is baz
Should display only if condition is not foo and not baz
Should display only if condition is not bar
This should be displayed only when cond2 is on.
Should display only if condition is bar
Postamble.
(My syntax may need to change. At the moment, two of tbese instructions
have variant forms ?if not? and ?elif not?. I'm not sure whether it's
XML-legal for a processing instruction to have a bare word in it. Should
I change these forms to "if-not" and "elif-not"?)
But there's a problem. An old familiar one, generic to the use of all
kinds of preprocessors. When I'm browsing XML errors in my Emacs
window, they point to the processed file rather than the original
input. Aaarrgghh!
Half the problem is already solved. There was a mis-bug in sgmlpre
that it passes through newlines from sections that are conditionalized
out. Thus the line numbers are correct.(Yes, I plan to add an
option to `fix' this.)
But the error file name that xsltproc sees and passes back is wrong.
Therefore: I request a command-line option in xsltproc:
--error-filename=foo
What it should do is tell xsltproc to plug in foo as the name of the
top-level input file in error report lines. I'll hack xmlto to
generate this option when appropriate.
Yes, I'm aware of the problem with entity inclusions. That's why I
specified "top-level input". A better solution would be for xsltproc
to interpret these processing instructions internally, so they would
work even within content included via entity references.
There are a couple of different ways we could go to solve the problem:
(1) You add support for ?if? and friends to xsltproc. Probably the
fastest route to a complete solution.
(2) You tell me you'll take a patch from me to implement them. I'd
have to learn the xsltproc code, so it would take longer, but I
can do that.
(3) You add --error-filename. Has the advantage that it could be used
with other preprocessors.
Your thoughts?
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
