Re: Component interfaces

Talking about the interface of components, I see two questions being asked here:

1) Should inputs/outputs be passed by position only (e.g. just one
sequence), by name only, or by a combination of both?

My take - If we draw a parallel between components and functions in
most programming languages, function inputs (called parameters), in
general have names. And I think this is a good practice. Instead of
having the XSLT component take a sequence of 2 documents, where the
first one is the stylesheet and the second one is the data on which
the stylesheet should be applied, I prefer to the XSLT component to
have two named inputs: "stylesheet" and "dataToTransform", each one
possibly validated with a schema.

2) Should we allow non-XML information to part of a component
interface? This is sometimes referred to as "parameters" (e.g. some
list of key/value) that can be provided to a component in addition to
the inputs.

My take - Adding parameters to the languages makes it more complex and
I can't think of a use case where this is really necessary. Also, if
parameters can be accepted as input, why not have output parameters?
Then can the output parameters of one component be connected to the
input parameters of another component?

Alessandro

On 1/10/06, Norman Walsh <Norman.Walsh@sun.com> wrote:
> 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.
>
>
>


--
Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/

Received on Thursday, 12 January 2006 02:02:07 UTC