[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] index-of and empty stuff

Subject: Re: [xsl] index-of and empty stuff
From: Ihe Onwuka <ihe.onwuka@xxxxxxxxx>
Date: Sat, 21 Dec 2013 21:56:11 +0000

ok, I can see how I got into this then. My control argument comes from
a source document field that may not be populated.

Thanks. That's useful to know - it does influence how one (or I)
should think about a problem - perhaps capturing the empty sequence
case further upfield rather than relying on index-of to bale me out
and do the right thing.

On Sat, Dec 21, 2013 at 9:18 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> On 21 Dec 2013, at 20:42, Ihe Onwuka <ihe.onwuka@xxxxxxxxx> wrote:
>> Of course I was not in the room . There may be a very good reason - it
>> is not at all apparent. If there is a good reason it's worth knowing
>> (in fact it's also worth knowing if there isn't a good reason) so
>> please bear with my question(s).
> If you want a historical evidence-based answer to the question, why was it designed like this, you won't get one. It's very rarely possible to find a specific decision minuted in enough detail to reconstruct the decision process.
> However, the general rationale for XPath 2.0 functions was:
> * arguments are classified into "input" and "control" arguments. Input data is data likely to come from the source document, while control arguments define how the input data is to be processed.
> * input data arguments generally accept an empty sequence, and the function generally either (a) treats an empty sequence as a zero-length string, or (b) returns an empty sequence if an empty sequence is supplied
> * control arguments generally do not accept an empty sequence.
> * in the case of index-of(), the first argument is considered a data argument, and the second a control argument.
> But of course there are inconsistencies, if only because this rationale was not retrospectively applied to 1.0 functions for compatibility reasons.
> Michael Kay
> Saxonica

Current Thread