Re: Regular expression functions (Was: Re: [xsl] comments on December F&O draft)

Subject: Re: Regular expression functions (Was: Re: [xsl] comments on December F&O draft)
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Tue, 15 Jan 2002 09:35:27 +0000
Bryan Rasmussen wrote:
>>>Well I wouldn't like to see xslt become just another way of
>>>applying regexes (and it never would)...
>
> are you sure? I sort of worry about this, the problem that people
> with skills in regex would have try to write minimal xslt and do
> regex instead.

I don't *think* that should be a problem. It's not as if the strings
that people will be working on with regexps will include element
structures (i.e. you won't get tags inserted into a string, and then
match on that). I think the aim for the regexp stuff should be to
support processing string values in much the same way as you can
currently process element structures.

> I have the same worry with xpath 2.0 to be honest, that people will
> try to do their processing with the conditional expressions and for
> syntax and that furthermore this make debugging harder(cause there's
> two places things could have an error right?)

I also fear that shifting the processing burden onto XPath 2.0 rather
than XSLT will make debugging harder. I've lost count of the number of
times that I've written a complicated XPath expression - maybe four or
five lines (!) - tried to run it and had the processor go "Error:
mismatched brackets" or something. Now imagine the 20 lines of XPath
that we'll be stuffing into the select attribute of xsl:result, and
you can imagine there'll be even more of a problem. But hopefully
processors will give you helpful error messages and we'll all be
writing this using editors that won't let us make these kinds of
mistakes in the first place...

I'd recommend writing to xsl-editors@xxxxxx to voice your concerns.

Cheers,

Jeni

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


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


Current Thread