Subject: RE: [xsl] Parsing a string From: "Michael Kay" <mhk@xxxxxxxxx> Date: Thu, 3 Jun 2004 22:52:18 +0100 |
> > This works, off-course, when $select is writen in that way, > but if it is, for > instance > > SELECT * FROM aTable ORDER BY anotherColumn > SELECT * FROM aTable ORDER BY anotherColumn WHERE aColumn='something' > > and worst > > SELECT * FROM aTable WHERE aColumn=(SELECT aColumn FROM > anotherTable WHERE > anotherColumn='somethingelse') > > then it won't work. Of course i can put a lot of xsl:if and > xsl:when, but > hopefuly there's another way to do it. > First define a grammar for the language that you wish to parse. Then you will know how big your problem is. It's possible that this will be a grammar that can be analyzed using regular expressions. In tha case you can use the regex facilities in XSLT 2.0 to parse it, or custom extension functions that invoke a regex library from an XSLT 1.0 processor. Regular expressions aren't powerful enough to parse all grammars, however, and your "worst case" appears to be a recursive grammar which is certainly too complex for this approach. XSLT/XPath is not a language that is particularly well suited to writing parsers. But I think your real problem is that you are scratching at the surface of a problem that is rather more complex than you imagine. If you can define a simple subset of SQL SELECT statements that you want to analyze, then you have some chance of succeeding. If you think you can start by handling very simple ones, and then tweak your code a bit whenever a new variant comes along, then you are going to get badly stuck. Michael Kay
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Parsing a string, xptm | Thread | XSLT help to generate FO-page-seque, Kenny Bogoe (BogoeMD |
RE: [xsl] encoding shift_jis into a, Matthew Simoneau | Date | RE: [xsl] Large transforms (was Re:, Michael Kay |
Month |