This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Regular expression functions (Was: Re: comments on December F&O draft)
- From: Jeni Tennison <jeni at jenitennison dot com>
- To: "Steven Noels" <stevenn at outerthought dot org>
- Cc: xsl-list at lists dot mulberrytech dot com, "Marc Portier" <mpo at outerthought dot org>
- Date: Thu, 10 Jan 2002 10:22:26 +0000
- Subject: Re: Regular expression functions (Was: Re: [xsl] comments on December F&O draft)
- Organization: Jeni Tennison Consulting Ltd
- References: <OKEDLKGMIPDOCJHOEDEFIEIICKAA.stevenn@outerthought.org>
- Reply-to: xsl-list at lists dot mulberrytech dot com
Hi Steven,
>> instance). It would be handy if the regular expressions could be held
>> in (global) variables because then they could be defined in content
>> (with CDATA sections) rather than in an attribute. However, that would
>> run up against the dynamic regular expression problem that David and I
>> talked about yesterday. I don't think it'll be too big a problem,
>> though - the regular expressions in XSLT are likely to be a lot
>> smaller than these, and not include tags (hopefully!).
>
> I will try to read and understand your discussion - because we
> already thought of storing the regexes in such a way but threw that
> idea away because it was affecting the readability of the regexslt
> transformationsheet
>
> I like all parameters to a certain action to be contained in the
> same area, and storing the regexes inside 'global variables' would
> conflict with that
I can see the advantages to having the regular expressions close to
the code that's generated from the regular expression - it makes it a
lot easier to understand what's going on, especially if you're
addressing sub-expressions.
On the other hand, if you have a standard regular expression, perhaps
something that you use in a lot of other regular expressions, it would
be handy to have that regular expression stored somewhere separate.
As a simple example, say I had a regular expression that matched
numbers in scientific notation:
[0-9]+(\.[0-9]+)?([Ee][+-][0-9]+)?
That's a bit of a mouthful to insert in all the regular expressions
where I want to test that part of the string is a number in scientific
notation. It would be handy if I could store that somewhere and just
call on it as required.
As I say, the problem with doing that is those ()s - I need to know
what ()s are used where in order to tell what subexpressions I'm
matching.
This could be solved in two ways:
- introducing a syntax (to XML Schema regular expressions - perhaps
you already have it) for non-capturing matches
- introducing a syntax for naming the subexpressions rather than
numbering them
I just said all that to give you an idea about where I was coming from
- I don't think that, at least in XSLT 2.0, this should necessarily be
introduced because it's just a convenience (that leads to lots of
other inconveniences!) rather than essential functionality.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list