- From: Alessandro Vernet <avernet@orbeon.com>
- Date: Wed, 28 Feb 2007 00:34:17 -0800
- To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
After our discussion about parameters during the call last week, and after reading Alex's elaborate reasoning [1], I feel increasingly attracted by the status quo. And this because its simplicity. With one condition though. But before we get into this, let's get some inspiration from plain old command tools. We have talked about having multiple classes of parameters. At some point we had up to 3 classes, each used for different things, and syntactically different. The drawback with one class seemed to be that we couldn't have an XSLT parameter called initial-mode and at the same time the value of stylesheet parameter which would be initial-mode. With command line tools, there is only one class of parameters; and it seems to work pretty well. For instance, you can both pass the "l" option to "ls" (ls -l) and list a file called "l". It is no magic, just a convention: adding a prefix in front of parameters in a given class. We can do the same when we define the XSLT component. For instance, we can say that the XSLT component take two parameters initial-mode and initial-template, plus any parameter that starts with "param-"; any of those parameter will be passed to the stylesheet without the "param-". In code, this gives: <p:xslt-2.0> <p:input port="source">...</p:input> <p:input port="stylesheet">...</p:input> <p:parameter name="initial-mode" value="..."/> <p:parameter name="param-initial-mode" value="..."/> </p:xslt-2.0> The same principle applies to inputs as well. Say you want to accept parameter documents, in addition to parameter values. For instance in the case of XSLT 2.0, where parameters can be documents. No problem, we can define the XSLT 2.0 components to map inputs that start with "param-" to parameters which name is equal to what follows "param-". Say: <p:xslt-2.0> <p:input port="source">...</p:input> <p:input port="stylesheet">...</p:input> <p:input port="param-employee">...</p:input> </p:xslt-2.0> Unlike the scheme where we introduce 2 classes of parameters by using a different syntax (named elements, generic p:parameter, or attributes), this extends quite nicely to the cases where we need more than 2 classes. Consider you want to create a component that exposes the functionality of a tool like wget or curl. Maybe you will want to use parameters to set HTTP headers, POST name/value request parameters, as well as other parameters like which user name or password to use. Here you already have 3 classes of parameters. But you can do all this with the simple <p:parameter> construct we already have, by following the convention of adding a prefix to parameter names. For instance: <p:wget> <p:parameter name="username" value="..."/> <p:parameter name="password" value="..."/> <p:parameter name="header-User-Agent" value="..."/> <p:parameter name="header-Authorization" value="..."/> <p:parameter name="post-firstname" value="..."/> <p:parameter name="post-lastname" value="..."/> </p:wget> Assuming that we use a naming convention in standard components, and encourage component authors to follow the same convention, my preference is to keep to status quo. Again, provided we follow some simple conventions, the construct we already have is both simple and solves all the cases we have seen so far. Alex [1] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0108.html -- Orbeon Forms - Web 2.0 Forms for the Enterprise http://www.orbeon.com/
Received on Wednesday, 28 February 2007 08:34:24 UTC