[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Regular expression functions (Was: Re: comments on
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|