The problem of variable placement

What happened was, @josteinaj added a comment to issue 182,
https://github.com/xproc/specification/issues/182 that made me think
we really needed to have the explanation about why variables have to
be declared at the top of a compound step explained somewhere that we
could point to.

So I wrote this:

https://github.com/xproc/notes/blob/master/vargroup/index.adoc

Near the end, I managed to formulate some thoughts about variables
that seem reasonable clear.

As I recall, last time we talked about this, we imagined describing
the solution in terms of adding groups and treating interstitial
variables as syntactic sugar for some set of nested groups with
variables that obey the current rules. I don't think that works.

But I think this does:

  Variables are analogous to steps which are connected to all of their
  following sibling steps (and variables) and the descendant steps
  (and variables) of those following sibling steps.

Analagous in the sense that they introduce a data dependency that way.

  The most liberal possible rule would be that variables are analogous
  to steps which are connected to any step which has references to
  them in XPath expressions.

(A less liberal rule would be to stick with all following/descendant
steps.)

In other words, a variable introduces a (transitive) dependency from
whatever it's connected to for the expression context node to any step
"after" it (in the same scope) that contains a reference to that
variable.

Observations:

1. I think that this is a coherent description of the problem that
could be described in the spec without ambiguity.

2. It would definitely make more work for implementors. In the liberal
case more work than in the less liberal case.

3. In most pipelines, authors would be able to use p:variable between
steps without any problems.

4. I don't think it would be impossible to understand the errors in
the (I'm going to guess fairly rare) cases where they did arise.

I don't know if this counts as feature creep or not, but the variable
thing is certainly a source of friction for pipeline authors.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com