Re: Implicit Inputs with Parameters vs Group

/ Alex Milowski <alex@milowski.org> was heard to say:
| 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.

Why do users have to understand this?

| We could restrict parameter
| calculation to inputs declared on the component type, but I'm not
| sure that is helpful to the user.

I'm sure it wouldn't be.

| 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.

There's definitely an issue right now with p:parameter/p:declare-parameter
on the language constructs. While it makes sense for p:declare-step to
have p:declare-parameter, it probably only makes sense for the language
constructs (group, for-each, etc.) to have p:parameter (and for them
to be understood to have p:declare-parameter name="*").

| 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.

Forcing me to add a group just to have a calculated parameter on a
single XSLT step seems like a burden.

| 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.

How is the "extra" input any "less used" than the other inputs?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.