Re: The Scope of Step Names

On the last call we had moderate agreement that the use of graph
terminology in a draft where we couldn't describe the construction
of the graph made most of feel uneasy.  As such, it was suggested,
with some agreement, that we remove such normative references to
graph terminology and use graphs as pictures to illustrate concepts.

As such, the term "Flow Graph" would need to go.  So, we can't
use that definition as you suggested.   My concrete suggestion was
based on an assumption that I'll state now in that you can
determine whether a port reference (p:input or p:declare-output)
by inspecting the XML instances in that:

   * you can't refer to steps in other pipelines or libraries.
   * everything you need can be described in terms of document

I'll reiterate that I've explored the flow graph model and I'm
using it.  The way that you derive such a graph is complex
and depends on choices in your implementation.  As such, I don't
think we want to every go to that level of detail.

My specific responses are below:

Henry S. Thompson wrote:
> Hash: SHA1
> Alex Milowski writes:
> Alex Milowski writes:
>> 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."

This has to go.  So, no flow graph and no "recursively"

>> 1. Step must be able to refer to other steps that are
>>    siblings (preceding and following) otherwise you
>>    can't connected steps at all.
> There is no preceding or following!  Siblings is it.  That's covered
> by "the flow graph of their container", i.e. any sibling of me can see
> me, because they're in the flow graph of my container.

Yes, it can just be 'siblings'.  It isn't covered by the flow
graph because we don't have one.  So, a reference can be to
a sibling element that is a step or step container.

>> 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).
> That's covered by "the flow graphs of the constructs therein",
> i.e. anything inside me can see me.

No flow graph, and so we have to traverse ancestors elements
which happen to all be step containers.  Even the [p:]pipeline
element can be consider to be a convenient conflation of
a pipeline and [p:]group.

>> 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).
> That's covered by the "recursively".

You can't recurse into sibling step container elements nor
sibling step container elements of ancestors.  So, unfortunately,
it isn't.

>> 4. Steps should be able to refer to siblings of
>>    ancestors.
> That's covered by the "recursively".

Not quite.  Again, you can only go to the siblings of
ancestors and not their descendants.

>> 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.
> That's not covered, so it's not allowed.

I think an explicit rule is much better for those reading
the specification.  It doesn't have to be a normative rule.  It
could just be a note to the reader say "For example, you can't...".

> So I think you've just expanded what we already said.  Clearly the way
> it's said in the current WD is not clear enough, but I don't think any
> _substantive_ change is needed to concur with what you've written
> above, just wording improvement, or examples, or both.

Minus recursing into siblings or siblings of ancestors, I'm not changing
what I believe to be our shared understanding.  I am just suggesting
we ditch the "flow graph" in terms of explicit rules on the instance
that can easily be following via inspection.

>> Of these, (4) is probably the most "controversial".
> Not controversial as far as I'm concerned.


--Alex Milowski

Received on Monday, 2 October 2006 18:37:31 UTC