[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

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

---

---

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

---