Sibling shadowing for variables should be allowed.

[alexmilowski]

In the current proposed XProc 1.0 errata (E.13), we clarified that variables can shadow up but not "left" (preceding siblings). We should remove this restriction in 2.0 to make XProc more like XQuery and XSLT. Variables can be redefined in both of those languages by following sibling elements.

[josteinaj]

Also, I don't know if it's been discussed in the WG but (like in XSLT) it would be useful if p:variable was not restricted to the beginning of a subpipeline:

https://github.com/xproc/specification/blob/50c0ed0fe6437bb8e52315eabc41fe6d6b3a8a35/langspec/xproc20/xproc20.xml#L340

I would prefer not having to wrap stuff in a p:group just because I want to define a variable:

<p:pipeline>
    <p:xslt>...</p:xslt>
    <p:group>
        <p:variable name="number-of-chapters" select="..."/>
        ...
    </p:group>
</p:pipeline>

(Having to wrap it in a p:group also makes it more difficult to connect steps sometimes.)

[vojtechtoman]

Does redefining of variables introduce new links to the dependency graph? I have to think about it some more, but there may arise ordering paradoxes if it doesn't. Or... maybe not - just recording the paranoiac voices whispering into my ear.

[ndw]

@vojtechtoman yes, it introduces new links because variable bindings that used to be an error are now simply shadowings of previous siblings. But I don't think there's any danger of paradox.

  <p:variable name="foo" select="3"/>
  <p:variable name="bar" select="$foo + 1"/>
  <p:variable name="foo" select="4"/>
  <p:variable name="baz" select="$foo + $bar"/>

is entirely equivalent to

  <p:variable name="foo.1" select="3"/>
  <p:variable name="bar" select="$foo.1 + 1"/>
  <p:variable name="foo.2" select="4"/>
  <p:variable name="baz" select="$foo.2 + $bar"/>

In both cases, I've left out the connections but they already exist in the language. Being able to shadow preceding siblings is just fiddling with the scope of variables.

@josteinaj everytime the "variables at the top of compound steps" rule comes up, we've tried to remove that restriction. We've always failed. I'll try to write something up about it.

[ndw]

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

[josteinaj]

@ndw Interesting read.

However, can't you can cause the same problem in v1.0 by just wrapping the variables with p:groups like this?:

<?xml version="1.0" encoding="UTF-8"?>
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:c="http://www.w3.org/ns/xproc-step" version="1.0">

    <p:load name="loader">
        <p:with-option name="href" select="static-base-uri()"/>
    </p:load>

    <p:group name="mine1">
        <p:output port="result"/>
        <p:variable name="foo" select="5">
            <p:pipe step="loader" port="result"/>
        </p:variable>

        <p:add-attribute match="/*" attribute-name="foo">
            <p:with-option name="attribute-value" select="$foo">
                <p:pipe step="mine2" port="result"/>
            </p:with-option>
        </p:add-attribute>
    </p:group>

    <p:group name="mine2">
        <p:output port="result"/>
        <p:variable name="bar" select="6">
            <p:pipe step="mine1" port="result"/>
        </p:variable>

        <p:add-attribute match="/*" attribute-name="bar">
            <p:with-option name="attribute-value" select="$bar">
                <p:pipe step="loader" port="result"/>
            </p:with-option>
        </p:add-attribute>
    </p:group>

    <p:store href="file:/tmp/out.xml">
        <p:input port="source">
            <p:pipe step="mine1" port="result"/>
        </p:input>
    </p:store>

</p:declare-step>

(edit: updated with working v1.0 example)

Or maybe I'm missing something. In any case, this seems to be yet another "simple for authors" vs "simple for implementers" issue.

[ndw]

Yes, that pipeline does seem to cause an undetected loop in XML Calabash. blush

And yes, even before that discovery :-), I was pretty much convinced that we should fix this in 2.0.