[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: regular expressions
> > NG validator; it is only 70 lines of code in Scheme, after all. Proved > > to be very useful for debugging. > > Very clever. But a naive implementation would just recursively > concatenate the strings to make a single regex strings. Could you > elaborate on the debugging advantage, i.e., how it makes it easier for a > schema writer to debug regular expressions? An implementation that 'just' concatenates strings is not naive, it is right. And this right implementation aids debugging because it makes regular expressions much more readable -- it is the experience, not a hypothesis. It makes a regular expression orthogonal: if there are repeating pieces, one has to edit a piece only once, instead of four times as in the original example. Besides, "just" concatenating strings is the right thing because it reveals non-regular grammars immediately through endless recursion; thus assuring that regular expressions remain regular. In few words: it makes regex debugging easier, because it allows to understand what you wrote at a previous attempt and fix bugs as many times as there are bugs, not as many times as the same bugs are repeated through cut and paste. > Jeni Tennison used the same idea with a slightly different syntax in her > DTLL proposal (I've lost the URL). Her idea had the added twist that an > application could receive the results of the regular expression parse as > a structured result, e.g., through a SAX API. Thus, using your example, > the string "(David Tolpen)David.Tolpin@n..." might produce the > 'infoset': > > <start> > <comment>(David Tolpen)</comment> > <local-part> > <atoms> > <atom>David</atom>.<atom>Tolpin</atom> > </atoms> > </local-part>@<domain> > <atoms> > <atom>nospam</atom>.<atom>net</atom> > </atoms> > </domain> > </start> This is a powerful syntax, but - it is a different problem. What I am talking about is not a query language, but a validation rule. - there are good tools that solve the problem of regular parsing, such as lex(1). adding XML output to them will do the above, but will still keep the problem of writing complex expressions for tokens intact. - it is a bold objective, but it cannot be solved with current tools; breaking a regex into named pieces can be implemented immediately and will make the life more fun. David
|
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
|