Re: Component interfaces

Alessandro Vernet wrote:
> 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.

My feeling is while named inputs will result in a more verbose language 
usage, I believe we can benefit from it, since it's more clear. However, 
I think that mixing stylesheet referencing with other inputs can be 
somewhat confusing.

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

Providing parameters is crucial, as it allows more flexibility in 
component usage. A simple example in XSLT: if you want to perform a tree 
flattening operation when some arbitrary element is found, a single 
stylesheet does the job (with a parameter defining the element name). 
Without parameters, you would have to develop a stylesheet per element. 
In extremis, you could have infinite different elements. Parameters 
should solve this issue.


Rui