Re: The Scope of Step Names

Alex Milowski wrote:

 > 1. Step must be able to refer to other steps that are
 >    siblings (preceding and following) otherwise you
 >    can't connected steps at all.

"Preceding siblings" would be enough IMO.

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

 > Of these, (4) is probably the most "controversial".  Here is a
 > simple example coming from a refinement of an actual pipeline:

I think that this is necessary. But again, I would change to
"preceding siblings", unless we have a really good reason to allow for
following siblings as well.

To me, constraining to "preceding sibling" is quite natural. It does
require that you order steps in a certain way, but that has the
benefit of making the pipeline easier to understand, as you can see
data "flow" from top to bottom (document order).

There is a precedent for looking at preceding siblings only: that of
XSLT variables within a template. E.g. if you write:

<xsl:variable name="a" .../>
<xsl:do-something/>
<xsl:variable name="b" .../>
<xsl:for-each ...>
   <xsl:variable name="c" .../>
   ...
</xsl:for-each>
<xsl:variable name="d" .../>

I am aware that XSLT does not have this exact same notion of container
we have, and has a quite different processing model, but purely from
looking at the syntactical nesting of elements you can draw a
parallel: when declaring "c", you have of course visibility on the
variables declared at the same level as xsl:for-each, but only those
declared before it. I.e. you will see "a", "b", but not "d". On the
other hand, "d" won't see "c".

Again, I am just illustrating with XSLT the fact that visibility based
on document order has a precedent in an XML-based language.

-Erik

-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Monday, 2 October 2006 16:43:22 UTC