To be honest, I think a production-quality tool that attempts this kind of
analysis should parse the XPath expressions properly.
Yes, we do need a tool that will not only work for a specific coding
style. It seems to me that for code that is heavily expressed within
XPath 2.0 expressions, the tool presented by Mukul is of limited use
only.
--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
On Thu, Jan 1, 2009 at 9:16 AM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
Since you require XSLT 2.0 it would be more precise to use
regular expression for stuff like this, like
//@*[matches(., 'true[^(] | false[^(]', 'x')]
(I like the x flag, which allows white-space for readability.)
yes, so long as you get the regexes right! This example only matches "true"
if it is followed by a character other than "(" - it fails to match
select="true" on its own.
To be honest, I think a production-quality tool that attempts this kind of
analysis should parse the XPath expressions properly.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--