W3C home > Mailing lists > Public > xproc-dev@w3.org > May 2009

RE: Detecting unbound options

From: <Toman_Vojtech@emc.com>
Date: Wed, 27 May 2009 09:52:12 -0400
Message-ID: <6E216CCE0679B5489A61125D0EFEC7870FABB592@CORPUSMX10A.corp.emc.com>
To: <xproc-dev@w3.org>
> 
> The most straightforward approach would be to add p:bound? as an XPath
> extension function.
> 
> This would map strings to booleans, and presumably work yield *True*
> for any inscope bound variable, parameter or option,
> i.e. p:boundp?('xyzzy') is True iff $xyzzy is not an error.

I don't think the function could ever work for parameters. You never
refer to them in XPath expressions. (Personally, I don't think that
unbound parameters are an issue at all).

But even with a function such as p:bound(), with an XPath 1.0-only
processor you would still need to use p:choose which would look similar
to that nightmarish nested try/catch. With an XPath 2.0 processor, you
could make use of the if() conditional in your XPath expressions.

A partial solution for XPath 1.0 processors could be a p:nvl(option,
fallback) which would check whether option is unbound, and if so, it
would return the value of the fallback...

> 
> A lighter-weight alternative would be to define p:unbound as a
> _variable_ in the static context for XPath evaluation specified to
> have a value distinct from any explicitly specified value that
> unspecified optional options would receive, so you could test for
> $opt=$p:unbound   This would only work with options, but would be
> simpler to implement.

Hm. This would probably mean that we would need to say that you are not
allowed to have options in the XProc namespace, or at least that you
can't use p:unbound because it is reserved. Doesn't sound that nice to
me...


Regards,
Vojtech
Received on Wednesday, 27 May 2009 13:53:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 May 2009 13:53:36 GMT