- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 12 Jan 2006 13:29:29 +0100
- To: public-xml-processing-model-wg@w3.org
Rui Lopes wrote:
> 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.
In XPL, this is done by name, and we define specific URL schemes,
"input:" and "output:", that can be used within components to access
extra inputs and outputs. For example, with XSLT, you would have:
<p:processor name="xpl:xslt">
<p:input name="stylesheet" infosetref="my-stylesheet.xsl"/>
<p:input name="data" infosetref="my-document.xml"/>
<p:input name="my-custom-input" infosetref="#my-custom-input"/>
<p:output name="data" infoset="my-result"/>
</p:processor>
and access "my-custom-input" with:
doc('input:my-custom-input')
You could do the same for XSLT 2.0's <xsl:result-document>:
<xsl:result-document href="output:my-custom-output" .../>
The same can be done with XInclude:
<xi:include href="input:my-custom-input"/>
> 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.
Are there components other than XSLT that really use this concept of
"parameter"? If not, then this could be specified for the standard
XSLT component. Interoperability would then be guaranteed this way.
-Erik
Received on Thursday, 12 January 2006 12:29:30 UTC