- From: Alessandro Vernet <avernet@orbeon.com>
- Date: Tue, 20 Feb 2007 21:30:10 -0800
- To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
Alex, On 2/18/07, Alex Milowski <alex@milowski.org> wrote: > I guess the point here is that this is my choice as a component > developer. I could certainly make the wrong choice in the eyes > of another developer. You put your finger exactly on the problem I have with those static configurations: the component developer making the wrong choice. For almost every case where component developers use a static parameter, there will be cases where pipeline author would like to make that parameter depend on the output of some other step. > The alternative here is a combinatorial explosion of variants of > components to allow different author-specified configurations of > component technology (e.g. XSLT 1.0, XSLT 2.0, XSLT 1.0 with a mode > specified, XSLT 2.0 with a mode specified, ...). The mode doesn't seem to be a good example: this is precisely a case where we would like to use a regular parameter, not a static parameter, isn't it? So the alternative if we want to have static checking for the XSLT version is to have two components: p:xslt-1.0 and p:xsl-2.0. (If I remember correctly was an option Norm favored over a component which automatically figures what engine to use.) Do you see any case, other than the XSLT version, where we would use a static parameter? Static parameters look like a Pandora's box to me, and at this point I feel pretty strongly against introducing those into the language. Alex -- Orbeon Forms - Web 2.0 Forms for the Enterprise http://www.orbeon.com/
Received on Wednesday, 21 February 2007 05:30:24 UTC