W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > January 2006

Re: Component interfaces

From: Rui Lopes <rlopes@di.fc.ul.pt>
Date: Thu, 12 Jan 2006 12:01:09 +0000
Message-ID: <43C64505.1040605@di.fc.ul.pt>
To: Erik Bruchez <ebruchez@orbeon.com>
CC: public-xml-processing-model-wg@w3.org
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

Received on Thursday, 12 January 2006 12:01:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:46 GMT