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

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,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

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

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