Re: [xslt] Pull request : xsltproc --fileparam

[Edouard Tisserant <edouard tisserant gmail com>]

> Wrt. to using libxml2's regexp implementation, it seems implement only
> a very basic dialect of regular expressions. AFAIK it doesn't even
> support captures (which are probably the premier reason to use
> regexp:match(...), and not just regexp:test() ...)

That's unfortunate. If libxml2 already includes it's own regexp
implementation, then there is little chance that a branch that relies on
external regex implementation would ever merge.

But is that true that current regexp implementation could never support
captures ?

When I look at the specs [1] xmlregexp.c is based on, capture isn't even
mentioned but only testing. But when I look at xmlregexp.c itself,
apparently parser deals with parenthesizes gracefully... Ok, I still
couldn't understand if corresponding generated automaton transitions
could be used to identify those captures at execution time. xmlregexp.c
is big, and I would need more time to make myself an idea if capture is
possible or not. No idea how much it would complicate backtracking,
also. Maybe the authors have an opinion on that ?

> https://github.com/smilingthax/songtools/tree/master/xsltlib/regexp/
> [...]
> Feel free to fork my implementation into a separate/standalone
> repositiory or even integrate it into lib(e)xslt...

Thanks !

My use case only needs match(), and unicode is a must. Since I can't be
sure that --fileparam will ever merge, I'll anyhow write a little
command line tool to process stylesheets with files passed as
parameters. I would then just have to port your PCRE based regex
extension into it. That could make it.

[1] https://www.w3.org/TR/xmlschema-2/#regexs