- From: Alessandro Vernet <avernet@orbeon.com>
- Date: Wed, 24 May 2006 17:13:26 -0700
- To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
On 5/24/06, Norman Walsh <Norman.Walsh@sun.com> wrote: > I've been expecting p:if/p:choose/p:pipeline/p:for-each/etc. to be > self-contained. As you've written it here, the p:when branch "reaches > out" of the p:choose to get the request. I think that makes it harder > to analyze the conditional, but maybe I'm mistaken. In most programming languages (and all the one I know), from the code inside an "if" or "for-ech" statement, you can access variables declared outside of that statement. You can write something like: shipForCheap($package) { $upsPrice = getUPSPrice($package) $fedExPrice = getFexExPrice($package) if ($upsPrice < $fedExPrice) { shipWithUPS($package) else { shipWithFedEx($package) } } It would seem utterly verbose to have to write instead: if ($upsPrice < $fedExPrice) using $package as $package { ... It is a different story however for the "return" value of the if/for-each however, as in most programming languages an if/for-each does create variables or labels that can be used later in the program. So for the output I agree and prefer to be explicit. Here we should be consistent with what we do for the pipeline output. So using as an example the <p:return> suggested in my previous email, the choose block would become: <p:choose> <p:output name="result"/> <p:when test="$validity = 'true'"> <p:step name="process-request"> <p:with-input name="document" select="$request"/> <p:with-output name="result" label="result"/> </p:step> <p:return name="result" select="$result"/> </p:when> <p:otherwise> <p:step name="return-error"> <p:with-output name="error" label="error"/> <p:return name="result" select="$error"/> </p:step> </p:otherwise> </p:choose> Alex -- Blog (XML, Web apps, Open Source): http://www.orbeon.com/blog/
Received on Thursday, 25 May 2006 00:13:40 UTC