Re: The problem of variable placement

nicely outlined, thanks.

I think

https://github.com/xproc/specification/issues/132

was partly trying to address this problem.

after offline discussions with Norm, I think we could consider
relaxing constraints on placement of p:variable and allow them
anywhere (a step can be) and throw an error if we hit a loop.

J



On 14 June 2015 at 23:30, Norman Walsh <ndw@nwalsh.com> wrote:
> 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

Received on Wednesday, 17 June 2015 15:31:14 UTC