[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: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Mon, 14 Jan 2002 09:45:57 +0000
regex for xml comments
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.



Jeni Tennison

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

Current Thread


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.
First Name
Last Name
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.