- From: Alex Milowski <alex@milowski.org>
- Date: Wed, 04 Oct 2006 08:45:18 -0700
- To: public-xml-processing-model-wg@w3.org
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