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

Hi Jeni, David,

> What I don't think we've thoroughly discussed yet is the idea of
> regexp matching templates (as David first suggested) vs. regexp
> matching instructions (which you need, I think, to cover the whole
> spectrum of requirements). Hopefully David's coming up with some kind
> of proposal that summarises it all ;)

good luck :-)...

also reminds me to think about unclear expected encoding support in regex
engines to plug in?
all regexing will need to be performed at the unicode level I guess? but
still...

for one thing e.g. our own jakarta-oro based regexslt solution currently
kinda suffers from unpredictable behavior related to the normal line-by-line
operation of the regex engine...

bad news however that the 'encoding' is not telling us if the file was
written on unix or windows machines... so the \r versus \r\n line mode
currently follows the setting of where-ever the process is running rather
then wherever the file was saved... so you don't know it $ will match and \s
will not or vice versa...

safest bet of course is to run always in the 'multi-line' mode... or define
the regex stuff inside xslt to not think in terms of lines? (unless there
would be some special unicode-endofline thing that would be intelligently
mapped onto by decoders?)

kind regards,
-marc=


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