- From: Tony Graham <tgraham@mentea.net>
- Date: Mon, 2 Mar 2015 17:30:56 -0000 (GMT)
- To: "XProc Comments" <public-xml-processing-model-comments@w3.org>
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