Re: a standard error port

On Mon, March 2, 2015 3:36 pm, James Fuller wrote:
> I think the convention today is to use try/catch to trap xsl:message
> ... but yes an apropos use case to consider; THANKS!

It wasn't permanent: just something that would have been there only long
enough for me to work out what wasn't happening.

Sometimes a xsl:message is just a message.  <xsl:message terminate="yes">
is something you'd want to catch, but a message with the value of a
variable isn't something you'd want to halt the processing over.

What about trace() [1]?  That certainly shouldn't throw an error.

Regards,


Tony.

[1] http://www.w3.org/TR/xquery-operators/#func-trace

> On 2 March 2015 at 15:37, Tony Graham <tgraham@mentea.net> wrote:
>> On Mon, March 2, 2015 12:57 pm, James Fuller wrote:
>>> as per ACTION: A-265-01
>>> (http://www.w3.org/2015/02/25-xproc-minutes.html#action01) ...
>> ...
>>> On first pass an error port on an atomic step might be an odd beast in
>>> xproc. The p:exec step defines an errors output port which would help
>>> diagnose unexpected errors ... or partial errors where some processing
>>> was possible. Similarly, I could imagine an errors port from steps
>>> that are facade into other languages, such as p:xslt or p:xquery. But
>>
>> Yes, just yesterday I was looking at how to get xsl:message output from
>> the XSLT in the pipeline in stf (https://github.com/MenteaXML/stf).
>> Couldn't get it to work.
>>
>> Regards,
>>
>>
>> Tony.
>>
>>
>
>

Received on Monday, 2 March 2015 17:31:18 UTC