Project

Profile

Help

Forums » Open Discussion »

XSLT command-line option '-m' - 'From Saxon 11.1 this option has no effect.'

Added by Philip Fearon almost 2 years ago

The Saxon 12 docs for the XSLT command-line options state that, for the '-m' option: 'From Saxon 11.1 this option has no effect.'

I used to frequently use this option on the command line as follows:

-m:net.sf.saxon.serialize.TEXTEmitter

In the Java API Feature Documentation the MESSAGE_EMITTER_CLASS field name is also no longer available.

Note: I've gone back through the different release of Saxon. Saxon version 9.9.0.1 was actually the last versions where this feature worked properly. In Saxon version 9.9.0.2 the following error message is given:

java.lang.IllegalStateException: Emitter must have either a Writer or a StreamResult to write to

Is there equivalent functionality in subsequent Saxon versions or has this feature been dropped?

This is quite important to me as I depend on xsl:message and the default built-in emitter makes more complex text output unreadable.

I'm also investigating colorising the output of xsl:message instructions using ANSI escape sequences - this wouldn't possible with XML escaping


Replies (2)

RE: XSLT command-line option '-m' - 'From Saxon 11.1 this option has no effect.' - Added by Michael Kay almost 2 years ago

The problem with defining callbacks such as the MessageEmitter and ErrorListener at Configuration level is multi-threading - there's no way to tell which of several concurrent transformations generated the message or the error. That's why we dropped it as a configuration option, and I guess the change at the command line was collateral damage. There's also been (for similar reasons) a history of changes to the callback API for messages before we converged on the Saxon 11 design of supplying a Consumer<Message>, which has the attractive property that it can be implemented by a simple lambda expression.

Instantiating user-supplied classes has always been a bit troublesome but I don't think that's a stopper.

I don't think there's any reason in principle we couldn't reinstate -m on the command line, implementing it by setting a property on the XsltTransformer rather than the configuration.

RE: XSLT command-line option '-m' - 'From Saxon 11.1 this option has no effect.' - Added by Philip Fearon almost 2 years ago

The lack of a TextEmitter option in the command line interface is no longer critical for me.

For VSCode use, I've coded a simple set of classes (targeting different Saxon versions) extending net.sf.saxon.Transform and overriding newTransformer(). Currently I'm just using setMessageListener but hope to use the MessageHandler API properly at some stage.

    (1-2/2)

    Please register to reply