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

[Jeni Tennison <jeni at jenitennison dot com>]

Hi Marc,

> This devils counterpart of your argumentation 'current
> implemenentation should not burden the conception off', would be
> some 'conception shouldn't get carried away purely based on
> notational ideas'

Yes :)

> - we end up forgetting why we had matcher elements? (or as I wrote
> it: not need them any more)

I can see your point - the grammar that's provided by the named
subexpressions gives you the nested structure that the matcher
elements (or xsl:regexp-template elements) would give.

What I'd suggest, if you want to use the named subexpression idea,
would put in place a rule that says that the regular expressions that
are used to define a named subexpression cannot itself contain a named
subexpression. That keeps them simple, keeps the implementation simple
(I think), and puts the burden of navigating a deeply nested hierarchy
on the matchers instead.

>> And I'd argue that we're going to need regular expression engines
>> specific to XSLT anyway (for support in XSLT, I know that your
>
> Jeni, with due respect (and I _did_ need to read your approach 3
> times to fully grasp the pure genious in it) people could argue in
> the end that what you describe *is* a specific regex engine ;-)

Um, yes... that's what I said, wasn't it? You're not going to be able
to use a regular expression engine that supports Perl regular
expressions, because XML Schema regular expressions aren't Perl
regular expressions (although they have a lot in common). And you're
not even going to be able to use an XML Schema regular expression
engine with XPath (I think) because XML Schema regular expressions
don't have some things that I think we're going to end up needing in
XPath (e.g. ^ and $).

> our participation in this discussion is helping us understanding
> more issues we maybe didn't think of (you _are_ a great help) in
> return we hope to maybe have helped this thought-train to get on the
> tracks

Definitely :) Your contributions have been very valuable, especially
in giving an implementer's viewpoint.

> On the approach itself and as stated above: while provig you *can*
> do it on top of current regex engine style of working, I think there
> is room enough for the hardcore regexengine people to find proof for
> doing this better directly based on the internals of their matching
> logic (and thus offer some new style API... think it would become
> their logical todo after accepting your \e()idea, no?

I agree that the tree would be better constructed within the regexp
engine. I don't think that building a tree is predicated on the named
subexpression thing - getting the result of any regular expression
through a tree would be incredibly useful (at least for XSLT), whether
you got named subexpressions or not.

>> But I think I'm still not very clear on your nested matcher
>> approach. Do you think you could use the examples above to
>> illustrate how your nested matcher would work?
>
> hope to have time tomorow to actually try regexslt out on the \para
> \bold \italic example haven't tried out anything like that up to
> know...

I look forward to seeing it.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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