Subject: Re: Regular expression functions (Was: Re: [xsl] comments on December F&O draft) From: David Carlisle <davidc@xxxxxxxxx> Date: Sat, 12 Jan 2002 21:11:19 GMT |
> Seriously? You write an extension function to create the relevant XML. > Or you do it in a pre-processing step. Maybe but as I'm offering the browser as essentially an "instant preview" I'm trying to avoid extensions (to give mozilla/netscape a chance). Anyway I could do it in perl or emacs (and that's what the omnimark that started the thread was doing) but the idea is to see where to put the boundary of what can be done in xslt... > Honestly, I can't see much difference between having to handle this > syntax and having to handle: ah that's easy I just use d-o-e for that:-) > But anyway, I like the LEX/YACC idea, and think it might be the way to > go. You basically create a grammar for the structure, using regular > expressions to represent the component parts. I'm not convinced yet actually, I think it duplicates too much existing xslt functionality. It's clear that lex/yacc accepts a larger class of grammars than regular expressions (I see Dimitre's already supplied the details), but I think (somehow) the extra functionality (which basically just always comes down to nesting, counting and storing information for look-ahead) is already present in xslt so the trick is to add regexp support (only) in a way that the extra arithmetic functionality can be pulled from xpath/xslt for those occasions when you need it. Since we argued a long time ago that xslt was turing complete (given an approximation to an infinite tape) everything's possible anyway so it's only a matter of convenience. Basically while doing regexp-replace (even extended ones where the replacement is a tree fragment) you are editing documents. If however you start writing LALR(1) Grammars for yacc then you have left document editing and become a parser-implementer (ie you've become a computer scientist, a terrible fate to befall anyone:-). > I am fairly convinced that it's possible to create an implementation > to do this, but given there's some resistence to extending Xpath with a parser for one fixed language, xpath (the evaluate function) you might find there's some resistence to adding a parser generator:-) (given a lex implementation you could (I think, haven't checked) implement an Xpath parser if you wished... David _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Regular expression functions (W, Jeni Tennison | Thread | Re: Regular expression functions (W, Jeni Tennison |
Re: [xsl] xalan error with plain t, Michael Engelhart | Date | Re: Regular expression functions (W, Jeni Tennison |
Month |