Re: [xsl] XSLT 3.0 Output and Serialization: Native XSLT message and error listeners?

[Philip Fearon <pgfearo@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxx> 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