a standard error port

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

Received on Monday, 2 March 2015 12:57:50 UTC