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

Implicit Inputs with Parameters vs Group

From: Alex Milowski <alex@milowski.org>
Date: Mon, 02 Oct 2006 08:08:48 -0700
Message-ID: <45212B80.2030109@milowski.org>
To: public-xml-processing-model-wg@w3.org

Right now we have the ability to declare a parameter on a step that
uses an input that the step does not use.  In some ways, that is
like declared an additional "unused" input.

<p:step name="transform" type="p:xslt">
    <p:input port="document" step="x" source="result"/>
    <p:input port="transform" href="xhtml.xsl"/>
    <p:param name="state" step="y" source="result"
             select="/options/@state"/>
</p:step>

I wonder if this additional dependency of another input could be
confusing to users in trying to understand what inputs are necessary
to satisfy a step before it can execute.  We could restrict parameter
calculation to inputs declared on the component type, but I'm not
sure that is helpful to the user.

In this case, we should have been able to replicated this with a
group.  I think we are missing something in the draft.  I had imagined
that group was used to calculate parameters:

<p:group name="scoped">
    <p:declare-output name="result" step="transform" source="result"/>
    <p:param name="state" step="y" source="result"
             select="/options/@state"/>
    <p:step name="transform" type="p:xslt">
       <p:input port="document" step="x" source="result"/>
       <p:input port="transform" href="xhtml.xsl"/>
    </p:step>
</p:group>

but that [p:]param element isn't allowed in the current spec and I
thought that was the whole point of [p:]group.

If we removed the ability to calculate parameters on arbitrary steps
and just had it on 'group', I think we'd have a simpler language.  We
could then see if users tell us that they need it on steps as
well.

 From an implementors perspective, I believe I have a clear story on
how to make both work but having extra inputs that aren't actually used
by the component means there is some notion of "before" on the step
that is harder to implement.  While that isn't a reason not to do it,
I do believe having a simpler language means more conforming
implementations.


--Alex Milowski
Received on Monday, 2 October 2006 15:35:51 GMT

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