[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: RE: Regular expression functions (Was: Re: comments on December F&O draft)
From: "Chris Bayes" <chris@xxxxxxxxxxx>
Date: Tue, 15 Jan 2002 00:51:12 -0000
d d music factory
 
> 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
that.
>   
> [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
http://www.bayes.co.uk/xml


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.