[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xsl-list
Subject:    Re: [xsl] XSLT 3.0 Output and Serialization: Native XSLT message and error listeners?
From:       Philip Fearon <pgfearo () googlemail ! com>
Date:       2013-01-22 11:29:34
Message-ID: CADV2FzQCS7k_je27Dytcb=YLjE3wPA-MJAjyWW69cuzoqwGkbg () mail ! gmail ! com
[Download RAW message or body]

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@saxonica.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@lists.mulberrytech.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@lists.mulberrytech.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@lists.mulberrytech.com>
--~--

[prev in list] [next in list] [prev in thread] [next in thread]