- From: <Toman_Vojtech@emc.com>
- Date: Wed, 27 May 2009 09:52:12 -0400
- 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 UTC