Subject: RE: Regular expression functions (Was: Re: [xsl] comments on December F&O draft) From: "Marc Portier" <mpo@xxxxxxxxxxxxxxxx> Date: Sat, 12 Jan 2002 12:38:08 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Regular expression functions (W, Chris Bayes | Thread | Re: Regular expression functions (W, David Carlisle |
Re: [xsl] Selecting first descendan, Christian Roth | Date | RE: Regular expression functions (W, Marc Portier |
Month |