W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > February 2007

Re: Chameleon Component Summary & Proposal

From: Alessandro Vernet <avernet@orbeon.com>
Date: Tue, 20 Feb 2007 21:30:10 -0800
Message-ID: <4828ceec0702202130g756d1f82x1c8d19901067281d@mail.gmail.com>
To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>


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.

Orbeon Forms - Web 2.0 Forms for the Enterprise
Received on Wednesday, 21 February 2007 05:30:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:41 UTC