Re: Chameleon Component Summary & Proposal

On 2/16/07, C. M. Sperberg-McQueen <cmsmcq@acm.org> wrote:
>
>
> I'm confused.  I would have thought that a request for an initial
> mode would be an application parameter, not a configuration
> parameter.
>
> I'm not sure whether this is a case of ontological subtlety,
> a typo on your part, or an ignorant error on my part.



That's a good point but let me clarify my thinking.

In the case of XSLT, we need to choose:

  * a implementation version
  * a way to invoke the transformation.

Certainly if the version is supplied statically, a pipeline processor
can "halt and catch fire" if the version is not supported.  That's my
qualification of a configuration parameter--something an implementation
wants to know statically so it can determine whether it can support the
component at all.

Basically, configuration parameters can be categorized as:

   * supporting actual component technology selection given and more
     general component type (e.g. xslt or "validation").
   * configuration information for a component that is required
     to operate.

That last bit is where configuration parameters blend into
application parameters.

For application parameters, the model I'm running on is that
of XSLT where the transformation will run regardless of whether
you specify the correct parameter values.  If you don't, you may
not get a good result from the transformation.

> Here's my examples:
> >
> > 1. The "munge" component that fetches a resource and makes it
> >     available after converting it to base64 for application data or
> > running tidy on
> >     HTML.  Here I want to specify a set of mime types that it
> > should accept:
> >
> >    <my:munge name="get.resource">
> >       <my:mime-type>application/pdf</my:mime-type>
> >       <my:mime-type>image/jpeg</my:mime-type>
> >       <my:mime-type>text/html</my:mime-type>
> >    </my:munge>
> >
> >    Here the component receives configuration parameter 'my:mime-
> > type' that has a
> >    value of a list of mime type values.
>
> Why is this a configuration parameter rather than an application
> parameter?  (This case does seem to be an ontological question.
> But unless my:munge is itself a chameleon step, I don't understand
> why it needs configuration parameters rather than application
> parameters.  And while I can understand why we might want some
> built-in step types to be chameleons, I guess I don't understand
> the utility of adding the complication of asking the question 'chameleon
> or tiger?'  every time a user defines a step type.


This is probably a case where the parameter value could be either
an application parameter or configuration parameter.  The issue here
would be that configuration parameters can produce lists of strings
(i.e. a list of mime types in this case) and application parameters
cannot.  That's an imbalance we might consider fixing.

The choice of configuration vs application parameter is up to the
component developer.  Right now we are saying that you
can't dynamically generate a configuration parameter.  If we
did allow dynamic setting of configuration parameters we'd
lose the basic requirement of static checking of the
configuration parameter value.

Any step defined by a user as a chameleon can (it seems to
> me -- am I wrong? why?) be defined instead as a tiger that
> never changes its stripes, just by treating it as a black box
> that doesn't have any internal structure we need to think about.



I think the real need here is for components like XSLT or "validation"
where, while you could define dynamic mechanism, you want
to allow the pipeline author to be very specific about the kind
of implementation they require.  This way we can use generic
names for standard component technology like "p:xslt" but
give the author control over asserting the actual specification
version.  I can certainly imagine similar uses for that in custom
components.

In the case of XSLT, the component could still operate by
looking at the version attribute.  That is, if the version isn't specified
by a configuration parameter, it could run in a "dynamic mode"
where it tries at best effort to supply the version of XSLT
specified.  Writing a pipeline that does that might not be
so inter-operable since there are three possibly outcomes:

  * a dynamic error is generated because you've run an
    XSLT 2.0 stylesheet through a implementation that only
   supports XSLT 1.0
  * an XSLT 1.0 stylesheet is run through and XSLT 2.0
    processor with a different result than what you expected.
 * the component dynamically chooses the right version
   and everything works as expected.


> 2. A simple ruby script component that needs the script to run.
> > ...
> >    but I'd rather write:
> >
> >    <j:ruby name="reverse.ABC">
> >       <j:script>
> >       <![CDATA[
> >          puts "<doc>" + "ABC".reverse + "</doc>"
> >       ]]>
> >       </j:script>
> >     </j:ruby>
>
> Again:  I don't see why the script can't be an application parameter
> rather than a configuration parameter.



It could.  Here the component absolutely can't run without the script
and a component developer could decide they want to statically
compile the script.

In my case, that is exactly what I want.  I want developers to be
able to write custom components inline.  I do *NOT* want them
to generate components on the fly due to security and other
considerations.  If they want to do that, they'll have to dynamically
generate a pipeline.

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.


> I like all of your examples.  I just don't see why they count as
> examples
> of needing complicated configuration parameters instead of complex
> application parameters.  Can you explain?


I think we have requirements for components like XSLT where we
really want a version specified as a static configuration.  Because
we want that, we'll make that feature generally available for
use (and abuse) by component developers.

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, ...).

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics