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: "Chris Bayes" <chris@xxxxxxxxxxx>
Date: Tue, 15 Jan 2002 00:51:12 -0000
> Dimitre and David have kindly explained to me that regular 
> expressions cannot be used for nested structures such as 
> these ones because a language that permits nested structures 
> are not regular languages, and therefore cannot be described 
> by regular expressions. (I think I got that right - I'm sure 
> I'll be corrected if I didn't ;)

Well I'm glad someone worked that out. I was sure there wasn't a general
solution. I have some books in a box somewhere that could have told me
> [Just to point out that there's no syntax for non-greedy 
> matches in the XML Schema regular expression definition - 
> I've posted to one of the comments list about this (I think) 
> but if you think it's a useful thing to have, I'd recommend 
> commenting to www-xml-query-comments@xxxxxx as well.]

I'd say it was more than useful. It's ok if you want to match something
exactly and you know what form it must take as in schema but for
transformations where the input is variable I think you need non-greedy
matches. Probably the D&D music factory can formalize that ;-)

> You could say that literal strings got special handling in 
> predicates in the same way that literal numbers get special 
> handling in predicates. So when you have a literal string in 
> a predicate it's equivalent to a call on a test() function of 
> some sort, with the context item as the first argument and 
> the string as the second argument. But this would 
> fundamentally change what text()[normalize-space()] actually 
> meant, which I think is quite a large backwards-incompatible change.

I just keep thinking of the way Mike explained optimisations and that
text()[normalize-space()] probably optimises to
text()[true] which would never be confused with text()['literal'] but I
guess that is implementation specific and not really relevant and I
maybe optimised my memory to much on this one ;-)

> The other 
> thing we'd discussed was the implicit assignment of variables 
> $1, $2 and so on - if you don't like typing perhaps they're 
> more your cup of tea.

Well they do look like special variables don't they?
> I kinda decided I didn't like the idea because XSLT never 
> implicitly assigns values to variables anywhere else.

Or creates nodes on the fly ;-)

> I also 
> thought that
> current-match() fitted in better with current-group(), which 
> does the same kind of thing (adds something to the available context).

I think that is neater somehow but what about m() ;-)

Ciao Chris

XML/XSL Portal

 XSL-List info and archive:

Current Thread