a standard error port

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

a standard error port

James Fuller-2
as per ACTION: A-265-01
(http://www.w3.org/2015/02/25-xproc-minutes.html#action01) ...

Issue #48

https://github.com/xproc/specification/issues/48

notes the need to help developers debug pipelines. Last week we
briefly discussed the idea of adding an errors port on each step,
which would emit c:* markup on encountering an error.

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
I think what we want to avoid is providing some alternative to
try/catch, which is the right way for handling (expected) errors in a
larger application.

Having an implicit errors output port is simply a short term tool to
help diagnose unexpected errors during development of the pipeline.
For example, I could see where one could pipe (taking liberties with
using future @pipe aka @from on the p:output) errors to view what is
going on.

<p:declare-step>

<p:input port="source"/>
<p:output port="result" pipe="mybrokenstep#errors">

<p:mybrokenstep name="mybrokenstep">
....
</p:mybrokenstep>

<p:mypossiblybrokenstep name="mypossiblybrokenstep">
....
</p:mypossiblybrokenstep >

</p:declare-step>

avoiding the wrapping with try/catch; maybe an errors port is
simulating a single step wrapped in an implicit try/catch though its
unclear if we need to attain this kind of parity/symmetry.

I don't think we would need to heavily revisit 4.6.1 The Error
Vocabulary section ... it seems to be generally applicable here.

Maybe we do not need an errors port on atomic steps ... maybe its a
top level output port or only on complex steps, though its hard to see
how more coarse grained error analysis helps debugging pipelines.

An implicit errors port (that doesn't need definition) could be useful
for debugging pipelines though I am not entirely confident that the
above is what folks are thinking would be useful.

Before I go full power on trying to describe this, requesting comment.

thx, Jim Fuller

Reply | Threaded
Open this post in threaded view
|

Re: a standard error port

Tony Graham-4
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.


Reply | Threaded
Open this post in threaded view
|

Re: a standard error port

James Fuller-2
Hello Tony,

I think the convention today is to use try/catch to trap xsl:message
... but yes an apropos use case to consider; THANKS!

J

On 2 March 2015 at 15:37, Tony Graham <[hidden email]> 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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: a standard error port

Tony Graham-4
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 <[hidden email]> 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.
>>
>>
>
>