Re: Parameter Calculations and Removing Complexity

Jeni Tennison wrote:

>> Further, there is a conceptual burden that I'm not certain
>> we really need for a 1.0 specification.  If the main use-case here is to
>> set XSLT parameters via inputs, that can be done by another step that
>> computes a stylesheet:
>>
>> <p:pipeline name="pipeline">
>>
>> <p:declare-input port="config"/>
>> <p:declare-input port="input"/>
>> <p:declare-output port="output" step="transform" source="result"/>
>>
>> <p:step name="bind-parameters"
>>         type="p:xslt">
>>   <p:input port="document" step="pipeline" source="config"/>
>>   <p:input port="transform">
>>      <xsl:transform version="1.0">
>>         <xsl:template match="/">
>>             <xslo:transform version="1.0">
>>                <xslo:import href="mytransform.xsl"/>
>>                <xslo:param name="color">
>>                   <xsl:value-of select="/config/@color"/>
>>                </xslo:param>
>>             </xslo:transform>
>>         </xsl:template>
>>      </xsl:transform>
>>   </p:input>
>> </p:step>
>>
>> <p:step name="transform" type="p:xslt">
>>    <p:input port="document" step="pipeline" source="input"/>
>>    <p:input port="transform" step="bind-parameters" source="result"/>
>> </p:step>
>>
>> </p:pipeline>
> 
> (You missed the <xsl:namespace-alias> that's necessary in the above.)
> 
> I am *absolutely certain* that users will find this extremely hard work. 
> I am pretty damned sure that the complexity it adds for the user far 
> outweighs the complexity that it removes for the implementer.

Yes, it is hard work.

> 
> So let's not remove step/source/select from <p:param>.

But... since you can easy set parameter values on the pipeline and have
those cascade into the XSLT step, you can easily pass configuration
*string* parameters into your XSLT transform.

So, as a 1.0 requirement, do we really need to compute such parameter
values?

You will *not* be able to pass elements as parameters to the
transformation and so would need generate an input transformation to do
that.  Once you have an input that is your configuration of a
transformation, the next likely step is to pass XML structures.  That
means that 'step/source/select' on [p:]param will fail to be
useful there and you'll be required to generate a transformation
on the fly that imports your regular XSLT.

You need a group construct with an ability to compute parameters
to actually explain how this works because the parameters can be
bound against arbitrary inputs.  Those bindings have to be
computed *before* the component is allowed to receive any inputs.

My suggestion was to explore whether we needed such complexity
in the language in 1.0 absent any *real* real world example that
can't be explained as a fancy way to set string parameters.

I have reviewed our use-case and requirements document and both
[p:]group and the 'step/source/select' attributes are *not* supported
by any of our use-cases.  All the parameter-like situations are
static configurations.  We either need to change our requirements
and add a use-case or decide that this is out of scope for 1.0.

I believe that we can add this in a later version XProc or even
a later working draft based on user response.

--Alex Milowski

Received on Wednesday, 4 October 2006 15:45:35 UTC