Re: Component interfaces

Erik Bruchez wrote:

 >
 > Rui Lopes wrote:
 >
 >  > 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.
 >
 > An XSLT stylesheet is an XML document like any other, and there are
 > uses cases where you may want to dynamically produce an XSLT
 > stylesheet from other pipeline steps. Our experience with XPL has been
 > that considering that components take only XML documents as inputs and
 > outputs, and not special-casing things like stylesheets or other
 > parameters, simplifies the language a lot while making it more
 > powerful.
 >
 > For reference, this is how executing an XSLT transformation can be
 > done with XPL [1]:
 >
 > <p:processor name="xpl:xslt">
 >   <p:input name="stylesheet" infosetref="my-stylesheet.xsl"/>
 >   <p:input name="data" infosetref="my-document.xml"/>
 >   <p:output name="data" infoset="my-result"/>
 > </p:processor>
 >
 > But you can as well refer to other infosets produced earlier in the
 > pipeline:
 >
 > <p:processor name="xpl:xslt">
 >   <p:input name="stylesheet" infosetref="#my-stylesheet"/>
 >   <p:input name="data" infosetref="#my-document"/>
 >   <p:output name="data" infoset="my-result"/>
 > </p:processor>
 >

I agree with you, in general. However, if the processor requires 
multiple input data (e.g. XInclude), should we label them with "data"? 
And what happens when multiple inputs are required by a given XSLT 
stylesheet, where we must distinguish between the default document and 
the others? Maybe different labels would solve the issue.

 >  > 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.
 >
 > I think the original question should translate as: do you need, in the
 > language, parameters that are not XML documents? If a component take
 > multiple inputs, then you can feed it with multiple XML documents. An
 > XML document can encapsulate XSLT stylesheet parameters, for
 > example.
 >
 > Historically, some languages have found the need for such special
 > parameters. With XPL, we have not included support for this concept,
 > and everything is done through XML documents. The clear benefit has
 > been language consistency and simplicity.
 >
 > In general, as a guideline, we must strive for simplicity when
 > designing a language. The more we can reduce the number of concepts
 > used, the better. In this particular case of parameters, I do not have
 > a definitive opinion, but I would still argue for simplicity first.


It's a good and clean approach, I must say. However, this leaves 
parameter specification and interpretation to component implementation. 
I'm not sure if we must leave it out from the model and language 
specifications.


Rui