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

Re: Detecting unbound options

From: mozer <xmlizer@gmail.com>
Date: Thu, 28 May 2009 09:37:45 +0200
Message-ID: <21d9ade60905280037s4876eeabg47a223736aebc359@mail.gmail.com>
To: Toman_Vojtech@emc.com
Cc: xproc-dev@w3.org
On Thu, May 28, 2009 at 9:29 AM,  <Toman_Vojtech@emc.com> wrote:
> Beautiful.
> Just a note about this:
>>> Alas, I think that would just trade a great big nested p:try/p:catch
>>> for a great big p:choose...
>> A small win, but a win !
> I think that it's not that small win, actually. The problem with
> try/catch is that the catch sub-pipeline is invoked whenever *anything*
> goes wrong, not just when some of the options are unbound. If, for
> instance, the directory-list simply fails to read the contents of the
> directory, the catch will run a second directory-list, which fails, too,
> and so on. Of course, you can check the error code in your catch
> sub-pipeline to detect what really went wrong, but that would be a)
> unreliable, and b) it would make the pipelines even more horrible.
> With choose, you don't have this problem.

May I also suggest that the choose is more "streaming-proof" than the try/catch

So indeed, that's a significant win

But I, again, voice for the suggestion

> 2) To add an attribute on p:with-option that says
> @bound-like-this-option="$foo" ; if foo is bound then the variable
> will be bound and the value will be the content of the select and will
> not be bound if $foo isn't bound

We could also add for more complex use case the p:is-option-bound() function

Received on Thursday, 28 May 2009 07:38:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:05 UTC