Re: Regular expression functions (Was: Re: comments on

Hi Mike,

>> I suspect that the introduction of user-defined functions in XSLT
>> will lead to more functions that do this [construct and return
>> trees], but don't know whether people would feel it was acceptable
>> for a built-in function.
>
> It's messy because of the problem that nodes have identity. You have
> to define whether two calls of the same function return the same
> tree or different trees.

You mean, assuming that current-match() returned the node tree
described in the mail, if I did:

  current-match()/mantissa == current-match()/mantissa

would the result be true or false? Or if I did:

  match($string1, $regexp1) == match($string2, $regexp2)

would the result be true or false?

I think that in both cases returning different trees would be more
consistent, since user-defined functions won't have the luxury of
being able to reuse trees.

> I guess one could say that it's explicitly implementation-defined,
> and no-one would worry too much about it. But it's also something
> you want to avoid if at all possible because constructing new trees
> is always expensive.

Is that because constructing *nodes* is expensive or is it the *links*
between the nodes within a tree that makes things problematic? If the
latter, then perhaps documentless nodes are a blessing ;) If the
former, then it's a good argument for nested sequences, so you don't
have to create nodes to provide structure.

For example, given the problems that I described about processing x,y
coordinates as pairs, there's a strong temptation to create pairs of
coordinates as 'coordinate' elements with 'x' and 'y' attributes,
rather than a simple sequence of integers. If sequences could be
nested, I wouldn't feel that temptation.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list