RE: [xsl] Parsing a string

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
  • Parsing a string
    • xptm - Thu, 3 Jun 2004 20:34:33 +0100
      • Jeff Kenton - Thu, 03 Jun 2004 15:55:30 -0400
        • Mayo - Thu, 3 Jun 2004 13:38:20 -0700
        • xptm - Thu, 03 Jun 2004 22:08:43 +0100
      • Michael Kay - Thu, 3 Jun 2004 22:52:18 +0100 <=