Re: Chameleon Component Summary & Proposal

On 15 Feb 2007, at 16:57 , Alex Milowski wrote:
> ...
> Here's my proposal based on what I've heard so far:
> ...
>   * A configuration parameter is specified on the component step
>     element by a simple typed attribute.  The value of that  
> configuration
>     parameter is a string value.
> ...
>   * All application parameters are specified via the [p:]parameter  
> element as
>     we specify in our current document (the status quo).
> ...
> Considering appropriate defaulting of ports, this gives us steps like:
> ...
> <p:xslt version="2.0" mode="toc">
>    <p:input port="transform">
>        <p:document href="stylesheet.xsl"/>
>    </p:input>
> </p:xslt>
>
> where we're asking for initial mode 'toc' and so on.

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.

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

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.

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

> 3. Specifying xquery pragmas and options

Ditto.

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?

Michael

Received on Saturday, 17 February 2007 01:38:06 UTC