Re: Component interfaces

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

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

But you can as well refer to other infosets produced earlier in the

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

 > 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

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.


Received on Thursday, 12 January 2006 11:23:02 UTC