Description Jesper Moller 2007-11-05 20:00:56 EST

As part of the XSL tooling proposal in bug 206826, this issue deals with validation of XSLT files.

XSLT files are tricky to validate, since their schema is version sensitive and contain fragments of the generated grammar mixed in with the XSLT parts. The initial pass at a validator must filter out the non XSLT-parts and only focus on the XSLT constructs themselves.

Here is a list of requirements as a starting point:

R1. The validator must be active for all XSLT files, and can run as part of the WTP validation framework.

R2. The validator must be able to work (even if in degraded mode) on incomplete templates (where include/imports cannot be resolved).

R3: XSLT files must be checked for structural validity:

R3.1: Valid XLST implies well-formed XML. This must be checked and reported in a fashion consistent with the regular WST XML validator.

R3.2: Any XML errors must be reported exactly once (i.e. avoid overlap with exsisting XML validator)

R3.3: Tags which are not part of the XSLT structure must be ignored.

R3.4: XSLT tags in use must be valid w.r.t. allowed attributes and element names in the XSLT namespace. Careful: There is a versioning rule to adhere to [1].

R3.5: XSLT tags in use must be valid w.r.t. the nesting of elements (i.e. xsl:with-param can only occur within xsl:call-template, etc.)

R4: XSLT files should be checked for logical validity:

R4.1: Named entities (i.e. template names, modes, keys, named parameters, variables) must be checked for existence (error) and non-use (warning). For extra credit, the warning can be a preference setting (may make sense for include files)

R4.2: XPath expressions must be parsable

R4.3: Variable expressions used in XPath expressions must be checked according to R4.1.

R4.3: Keys used in XPath expressions must be checked according to R4.1.

R4.4: XML namespace prefixes used in XPath expressions must be active in the context they appear in.

R4.5: XPath functions must be checked for names and arity. A preferences section can be used to declare extension XPath functions.

OK, this is possibly too much for an initial implementation, but at least then it's recorded somewhere. In fact, much of this may be implemented by constructing a JAXT Transformer object and watching for errors, but this may not provide R2, I'm not sure.

And I didn't even get to:

R5: Statically validate the output of the XLST template. A theis was written on this a few years back [2].

Comments, rants, raves?

[1]: http://www.biglist.com/lists/xsl-list/archives/200410/msg00751.html
[2]: http://www.daimi.au.dk/~madman/xsltvalidation/