Explaining it this way, I can now understand why capturing xsl:message
output is outside scope for the XSLT specification, I will look
further into a possible XProc solution - though with the Calabash
XProc processor I fear I need either to write my own MessageListener
or change the existing Java logging configuration files.
I guess anyone needing to pre-process xsl:message output can still do
this within the XSLT that's running, using a similar technique to that
prescribed for message localization.
On Mon, Jan 21, 2013 at 11:51 PM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
I think the question of how to capture xsl:message output (and for that
matter, xsl:result-document output) is a question of API design, which is
outside the scope of the spec itself.
The JAXP spec rather clumsily maps xsl:message output to calls on the
warning() method of the ErrorListener. This is clumsy because warning() only
accepts strings, while xsl:message outputs XML, and the right mapping from
the XML to a string isn't clear. Saxon on the Java platform doesn't
implement this JAXP mapping, it instead has its own MessageListener
interface.
Connecting the xsl:message and xsl:result-document outputs of one stylesheet
to the inputs of another is, I think, in the domain of XProc rather than
XSLT.
Michael Kay
Saxonica
On 21/01/2013 20:05, Philip Fearon wrote:
Dear list,
With XSLT 1.0 and 2.0 there is (so far as I know) no specified way of
assigning a 'native' XSLT listener to the message output from
xsl:message instructions or to the error output.
Will this change with the introduction of XSLT 3.0? If so, are there
any publicly available details on this - or perhaps this is planned
for 3.1? Does message and error listening exploit the xsl:output
declaration? Can it exploit the new streaming capabilities in XSLT 3.0
(like xsl:merge) ?
Ideally, I would like to assign an XSLT module to handle all message
and error events - this would avoid needing to shell out to C# or Java
classes using implementation specific interfaces (which just feels
wrong).
A typical use case for this would be for XSLT test frameworks
implemented in XSLT that need to test all message and error outputs
for a given input.
Thanks
Phil Fearon
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--