- From: James Fuller <jim@webcomposite.com>
- Date: Wed, 17 Jun 2015 17:30:46 +0200
- To: Norman Walsh <ndw@nwalsh.com>
- Cc: XProc WG <public-xml-processing-model-wg@w3.org>
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