Code Inspections in XPath

Reports comparison of the name() function with a string that contains a colon (:). Such usages usually indicate a hardcoded namespace prefix in the comparison. As a result, the code will break when run against XML that uses another prefix for the same namespace.

Example:

<xsl:if test="name() = 'xlink:href'">...<xsl:if>

Powered by XPathView + XSLT-Support

Reports an implicit conversion among the predefined XPath-types STRING, NUMBER, BOOLEAN, and NODESET. Helps to write XSLT scripts that are more expressive about types and prevents subtle bugs:

Example:

<xsl:if test="foo" /> is not the same as <xsl:if test="string(foo)" />

The first test checks whether the element "foo" exists (count(foo) > 0); the latter one however is only true if the element actually contains any text (string-length(foo) > 0). Suggests making the type conversion more explicit.

Use the controls below to customize the inspection.

• Enable or disable implicit conversions between certain types

• Always report explicit conversions that do not result in the actually expected type, for example, <xsl:if test="number(foo)" />

• Ignore conversion from NODESET to BOOLEAN by using the string() function as a shortcut for writing string-length() > 0.

Reports a type conversion with a string(), number(), or boolean() function where the type of the argument is the same as the function's return type or if the expected expression type is any. Suggests removing the unnecessary conversion.

Powered by XPathView + XSLT-Support

Reports the name of an element or an attribute that is used in an XPath-expression but is missing in the associated XML file and is not defined in the referenced schema. This prevents problems caused by typos in XPath-expressions that otherwise occur when running the script and may even happen not to be recognized immediately.

Example:

<xsl:template match="h:txtarea" />

If the h is bound to the XHTML namespace, the inspection will report this part of the match expression as an unknown element name because the correct name of the element is "textarea".

Powered by XPathView + XSLT-Support

Reports accidental usage of zero in a predicate index or in a comparison with the function position(). Such usage is almost always a bug because in XPath, the index starts at one, not at zero.

Example:

//someelement[position() = 0] or //something[0]

Powered by XPathView + XSLT-Support