- 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