Subject: Re: Regular expression functions (Was: Re: [xsl] comments on December F&O draft) From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Mon, 14 Jan 2002 09:45:57 +0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Regular expression functions (W, Marc Portier | Thread | RE: Regular expression functions (W, Marc Portier |
Re: [xsl] what type of encoding?, Oscar Rueda | Date | Re: [xsl] Function arguments (was r, Joerg Pietschmann |
Month |