Along the way of developing smallx, I realized that I wanted to allow
embedding of vocabulary elements that represented pipeline steps. The
model of have a 'processor' element with some number of fixed vocabulary
steps becomes far more unworkable when the configuration requirements
of the parameters become more complex.
For example, in the current version of smallx you can configure
XML Schema validation by simply embedding the namespace
maps into the step definition.
For example, for the web service that accepts messages for mathgrid.org
the following step specifies the validation of the incoming message
with XML Schema:
<p:validate assert="true">
<p:map href="ping.xsd"/>
<p:map
namespace="http://www.milowski.com/Vocabulary/Math/Monos/2005/1/0"
href="monos-vocabulary.xsd"/>
<p:map
namespace="http://www.milowski.com/Vocabulary/Math/CuttingStock/2005/1/0"
href="cstock.xsd"/>
</p:validate>
If that was specified with a more processor/parameter-like vocabulary,
that would have to allow an embedded "document" as the configuration:
<processor name="validate">
<parameter name="namespace-map">
<p:maps>
<p:map href="ping.xsd"/>
<p:map
namespace="http://www.milowski.com/Vocabulary/Math/Monos/2005/1/0"
href="monos-vocabulary.xsd"/>
<p:map
namespace="http://www.milowski.com/Vocabulary/Math/CuttingStock/2005/1/0"
href="cstock.xsd"/>
</p:maps>
</parameter>
</processor>
Now, that isn't that bad, but having an extension vocabulary model for
steps allows components to do rather special operations. In smallx, the
subtree iteration and trapping for errors is just another component
whose step vocabular allows embedding other steps.
For example, to trap validation errors and return something to the
client, smallx has a [p:]trap step that allows embedding of the
normal processing case and the exception handling case.
Here is that web service pipeline with the trapping of validation
errors:
<p:trap>
<p:validate assert="true">
<p:map href="ping.xsd"/>
<p:map
namespace="http://www.milowski.com/Vocabulary/Math/Monos/2005/1/0"
href="monos-vocabulary.xsd"/>
<p:map
namespace="http://www.milowski.com/Vocabulary/Math/CuttingStock/2005/1/0"
href="cstock.xsd"/>
</p:validate>
<p:on-error>
<p:template>
<mg:error>
You're document was not valid due to: <xsl:value-of
select="/c:error-context/c:error"/>
</mg:error>
</p:template>
</p:on-error>
</p:trap>
If the document passes validation, then the step passes the results
of the validation through with the PSVI annotations. Otherwise, the
result is an [mg:]error element.
In my mind, this all comes back to a model of extensible actions--much
like XSLT. You can register an extension with your implementation and
create your own pipeline step with its own parsing of its representation
vocabulary.
...which comes back to a *requirement* of extensibility. If I were to
refine that requirement, I'd want to allow embedding of custom
vocabularies for pipeline steps.
--Alex Milowski