Proposal: raising errors

Folks,

Currently, steps are allowed to raise errors according to their
semantics. This raises the question (no pun intended): why can't a step
defined by a pipeline (e.g., contained in a library) raise errors
according to its semantics? This could be a feature similar to XSLT's
<xsl:message terminate="yes" />, or throwing exceptions in Java.

Therefore, I would like to propose adding a new construct/micro-step to
our language, p:error, with the following syntax:

<p:declare-step type="p:error">
   <p:output port="result"/>
   <p:option name="errcode" required="yes"/>
   <p:option name="description"/>
</p:declare-step>

The output of this step would be compliant with the (yet to be defined) 
error vocabulary from the spec. It is worth noticing that the declared 
options (errcode/description) may differ, in order to be in tune with 
the error vocabulary.

Having this step, it would open the possibility of creating assertions
and semantic validations. For instance, taking the Example 6 from the
spec, it could be possible to do:

<p:choose name="version">
   <p:when test="/*[@version = 2]">
     <p:output port="result"/>
     <p:validate-xml-schema>
       <p:input port="schema">
         <p:document href="v2schema.xsd"/>
       </p:input>
     </p:validate-xml-schema>
   </p:when>

   <p:when test="/*[@version = 1]">
     <p:output port="result"/>
     <p:validate-xml-schema>
       <p:input port="schema">
         <p:document href="v1schema.xsd"/>
       </p:input>
     </p:validate-xml-schema>
   </p:when>

   <p:otherwise>
     <p:output port="result"/>
     <p:error>
       <p:option name="errcode" value="xerr:1000" />
       <p:option name="description" value="Invalid input document" />
     </p:error>
   </p:otherwise>
</p:choose>


This could leverage the creation of pipeline libraries that enforce
specific semantics of pipelines without having to dig deeper into
creating native components for a specific XProc implementation.

I think pipeline authors will easily grasp this construct, and
implementors may easily add support for this construct, IMHO.

The only relevant aspects on this proposal that may conflict with the
rest of the spec concerns assigning p:error's output port to the special
"error" port, which indicate that p:error may have to be spec'd as a
language construct instead of a required step (hope not to be
overlooking on this).

Thoughts?


Cheers,
Rui