0

I've not tried it yet.

Can we update the value of p:variable anywhere else in the pipeline i.e. after its valid declaration at start of some step? If not then why? Also what is the best way of doing this, if I really need to do or at least simulate it.

ask-dev
  • 606
  • 2
  • 13
  • 30
  • Can you comment on why you need this? There might be other ways of achieving what you are trying to do. – grtjn Nov 30 '11 at 06:30
  • Let's say I have a p:variable name='state', now below its declaration I'm going through a long p:choose and I want this state variable hold some value based on any p:when getting executed so that I could do something based on the variable [state]'s current value afterwards. What is the best way of achieving this in XProc if above is not possible? – ask-dev Nov 30 '11 at 07:59
  • You need to bend your mind to not need variables that way. You can however make use of arguments (options, params) for instance. Put the logic that depends on $state in a separate p:declare-step, then call that step from within the choose alternatives with the appropriate value of $state. – grtjn Nov 30 '11 at 14:34
  • I could give a more detailed solution if you append a practical example case to the question.. – grtjn Nov 30 '11 at 14:36

1 Answers1

0

I forwarded your question to the xproc-dev mailinglist. Apparently, the recommendation seems to contradict itself. Section 5.7 ( http://www.w3.org/TR/xproc/#variables-options-parameters ) says quite explicitly that shadowing should be allowed in specific conditions. But section 3.2 ( http://www.w3.org/TR/xproc/#scoping ) says that reusing the same variable name in a scope is an error. The consensus was though that this should in principle work:

<p:variable name="myvar" select="1"/>
<p:group>
    <p:variable name="myvar" select="2"/>

However, XMLCalabash (0.9.40) chokes on this. You might try Calumet or other processors though..

grtjn
  • 20,254
  • 1
  • 24
  • 35