W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2009

RE: Three requests related to regular expressions

From: Michael Kay <mike@saxonica.com>
Date: Tue, 15 Sep 2009 10:29:01 +0100
To: 'Krzysztof Maczyński' <1981km@gmail.com>, <public-qt-comments@w3.org>
Message-ID: <862EBF43509543E78EED8B055F2670F4@Sealion>
> 
> The following 3 requested features (suitable for XPath 2.1, I 
> presume) are motivated by something I've tried to do at work 
> recently (amd used a workaround).
> 
> 1. Please provide versions of matches, replace and tokenize 
> that do not treat their argument as a regular expression. The 
> use case is to deal with trimming, extracting or otherwise 
> processing of arbitrary strings, potentially read from some 
> input and not hard coded in the expression.

The WGs have already approved a change for XPath 2.1 that does exactly this.
It is achieved using a new option setting in the flags argument to these
functions.
> 
> 2. Please lift the requirement that some functions (replace, 
> tokenize) cannot work with a regular expression matching the 
> empty string when ^ or $ is involved. These should be thus 
> consistently treated as virtual characters for the purpose of 
> matching.

I'd like to see evidence that this is needed in the form of use cases that
can't readily be solved using existing facilities. I think that specifying
this could be quite complicated, and it therefore needs strong justification
that demonstrates the benefits.
> 
> 3. This takes 1. a bit further. I sometimes need (not only in 
> XPath, also e.g. in ECMAScript, but that's another pair of 
> shoes) a regular expression that matches only one string 
> which is computed, not known in advance. A function producing 
> such an expression from any string would be useful.
> 

We did consider, as an alternative to the new option setting in (1) above,
providing a function that constructs a regular expression from a string by
escaping any special characters. However, the solution in (1) seemed to be
simpler and sufficient to meet most of the use cases. If you have a use case
that isn't satisfied by this facility, it would be interesting to see it.

Please note, it's convenient to the WG if requests for enhancements can be
raised in the public W3C bugzilla system as bugs against the 2.1 working
drafts. This is the way the WG manages its agenda and keeps track of
discussions on each proposal. It would be helpful if you could raise such
entries, but if you can'd do this conveniently, then the WG can do it on
your behalf.

Michael Kay
(personal response)
Received on Tuesday, 15 September 2009 09:29:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:40 UTC