[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: RE: Regular expression functions (Was: Re: comments on December F&O draft)
From: "Marc Portier" <mpo@xxxxxxxxxxxxxxxx>
Date: Mon, 14 Jan 2002 13:43:13 +0100
hardcore regular expressions
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.