Component interfaces

I was struck last week by Alex's observation that in his
implementation almost everything is a component. Then when I was
thinking about iteration in reading the thread following Jeni's
message, and it struck me that we could take the following approach:

Every component accepts as input a (possibly empty) set of parameters
and a sequence of nodes. It produces as its result a sequence of
nodes. Anything with that interface can be a component.

Then each component must describe what it does with its sequence of
inputs. Some components, like XInclude or validation, can just perform
their function on each node of input producing a corresponding node of
output. Other components can raise an error if they receive the wrong
number of inputs. There's even the potential to be more flexible. I
can imagine, for example, that an XSLT component might take a
"stylesheet" parameter and perform that stylesheet over each of it's
inputs. But if the stylesheet parameter wasn't specified, it could
accept the first input node as the stylesheet.

Note that we can invent several namespaces if we want to, so that
parameters can be expressed as attributes on the "component element"
or passed to the component in a document in the "parameters"
namespace. Similarly, we can (perhaps) reduce errors to "producing an
output node in the 'error' namespace".

I haven't given it a lot of thought yet, but at first blush, I like
the conceptual simplicity.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.