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

Re: Chameleon Component Summary & Proposal

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Fri, 16 Feb 2007 12:27:01 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <87ps8af1y2.fsf@nwalsh.com>
/ 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.

Received on Friday, 16 February 2007 17:27:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:49 GMT