Re: The Scope of Step Names

/ Alex Milowski <alex@milowski.org> was heard to say:
| In section 4.1.2, we have:
|
| "The scope of component names is the flow graph of their container and
| the flow graphs of the constructs therein, recursively."
|
| I think should have been 'step names'.  component names are global
| as they represent a type of component that can be used in a step.
|
| If you then trace down the definition of a flow graph, things become
| very unclear.
|
| Per last week's discussion, I think we need to delete the term flow
| graph (and section 2.4) from the specification and just define the scope
| of step names explicitly.

I think that is a fair paraphrase of what we concluded last week. I
haven't yet carefully considered what violence that does to the spec.

| I think we have the following rules to consider:
|
| 1. Step must be able to refer to other steps that are
|    siblings (preceding and following) otherwise you
|    can't connected steps at all.

Given that we forbid loops, I don't think you need to consider
following siblings. When we get to defaulting, document order will
definitely become an issue, so I'm content to say that document order
is significant even when you don't have defaulting.

| 2. Steps must be able to refer to their step container
|    because otherwise you can't bind to the input of
|    the container (e.g. the input of the pipeline).

Right.

| 3. Steps should be able to refer to ancestors so that
|    you can refer to ancestor inputs (e.g. a descendant
|    may want to refer to the pipeline input).

Right.

| 4. Steps should be able to refer to siblings of
|    ancestors.

The preceding-siblings of ancestors at least.

| 5. Steps should not be able to refer to any descendant steps
|    of ancestors or siblings of ancestors that are
|    step containers.  That is, you can't point inside a
|    step container that isn't your ancestor.

Right.

| Of these, (4) is probably the most "controversial".  Here is
| a simple example coming from a refinement of an actual
| pipeline:
|
| <p:pipeline name="example">
|   <p:declare-input port="pipe-input"/>
|   <p:declare-input port="metadata"/>
|   <p:declare-output port="pipe-output" source="main!output"/>
|
|   <p:step name="prep-metadata" type="p:xslt">
|       <p:input port="document" step="example" port="pipe-input"/>
|       <p:input port="transform" href="prep-metadata.xsl"/>
|   </p:step>
|
|   <p:viewport name="main">
|     <p:declare-input port="part"
|                      step="example" source="pipe-input"
|                      select="/doc/section"/>
|     <p:declare-output port="output"
|                       step="transform" source="result"/>
|     <p:step name="insert" type="p:insert">
|        <p:input port="document"
|                 step="main" port="part"/>
|        <p:input port="insertion"
|                 step="prep-metadata" port="result"/>
|     </p:step>
|     <p:step name="transform" type="p:xslt">
|        <p:input port="document"
|                 step="insert" port="result"/>
|        <p:input port="transform" href="part.xsl"/>
|     </p:step>
|   </p:viewport>
|
| </p:pipeline>
|
| In the above example, the step 'insert' refers to the sibling
| step 'prep-metadata' of its ancestor 'main'.

I think that has to be allowed.

                                        Be seeing you,
                                          norm

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