Re: Chameleon Component Summary & Proposal

/ Alex Milowski <alex@milowski.org> was heard to say:
| This is my summary... so correct me if I'm wrong.

It all sounds good to me.

[...]
|  * allow configuration parameters to be child elements of the component
| step
|    elements.
|
| That last point I find really interesting.  I think it would simplify
| setting configuration
| parameters that have large text values as well as allow for lists.
|
| 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>

I'd be happy with this extension as long as we mandated that the
"parameters as sub-elements" have to be recognized by the processor.
In other words,

   <my:munge name="get.resource">
      <my:mime-type>application/pdf</my:mime-type>
      <my:mime-type>image/jpeg</my:mime-type>
      <other-ns:other-param>something</other-ns:other-param>
   </my:munge>

is a static error unless I recognize the other-ns namespace.

For interoperability, I don't want some sub-elements getting ignored
by some processors.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.