- From: Alex Milowski <alex@milowski.org>
- Date: Sat, 14 Jan 2006 09:45:33 -0800
- To: public-xml-processing-model-wg@w3.org
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
Received on Saturday, 14 January 2006 17:45:48 UTC