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

Subject: RE: Regular expression functions (Was: Re: [xsl] comments on December F&O draft)
From: "Marc Portier" <mpo@xxxxxxxxxxxxxxxx>
Date: Mon, 14 Jan 2002 13:43:13 +0100
Hi Jeni,

>
>
> 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 :)

although my personal (non-devils) believe is that well choosen abstract
notations do help us to think about otherwise hard to conceive concepts

I think you've proven this more then once in this thread.

>
> > - 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.

indeed

>
> 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.

great idea, puts their introduction back to shorthands for hard to write
regexes

>
> >> 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
oeps, my *other* understanding of argue I guess, sorry for that

> 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.
>
yours indeed is to offer enough use cases that break my current
implementation :-)
I 'think' I found what the problem was... just need to think of a clean fix
:-(

> > 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.
>
right again, I only tried to state that the introduction of \e() could be
the incentive to build such a new style API.
also for those regex engine builders that are not considering any xslt usage

> >> 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.
have to tackle the bug first, like to warn about not having the
regex-template names you had in your later mails, think that's less of an
issue though

-marc=
>
> Cheers,
>
> Jeni
>
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>


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


Current Thread