Re: [xsl] Debugging XSLT

[David Tolpin <dvd@xxxxxxxxxxxxxx>]

> > How can I assert that the stylesheet produces a nice-looking XHTML?
> > Since browsers for XHTML already exist, isn't it rather simple
> > to just launch a browser from XSLT 2.0 stylesheet and just see
> > whether the result is nice?
>
> I am currently trying to track down an XHTML problem. I would love to 
> have the transformation break at the point of the error. I hate having 
> to view source and copy the contents to a new file to submit it for 
> validation (the render is dynamic).
>

1) Validity errors are just one kind of many, there are neither
the most frequent nor the most nasty errors. Providing one 
error-prone mechanism for one kind of errors is a mistake.

2) I do not propose to 'copy the contents to a new file' to 
submit it to validation. Cut-and-paste is not hte only IPC
(inter-process communication) technology. The XSLT specification
could describe an extension mechanism usable for pluginng
debugging/assertion facilities.

3) You do not want the transformation to break each time an error
condition is met, it is waste of time. Instead, you want as
many reports about failed assertions as feasible during one
run. Embedding back-references to the code of the stylesheet
and to the input tree into the transformation result 
and using a tool to check and report
assertion failures (not just validity assertion, and obviously
not just vcalidity assertions using one schema language) is
much better for the following reasons:

- it is as powerful fo the same validation task
- its is more powerful for debuggin in general since it allows
  to provide other types of assertions too, using Schematron, for example;
- it is easier to implement and support
- it provides clear separation of layers
- it does not contaminate the language with ugly kludges solving
  partial problems.

David Tolpin
http://davidashen.net/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list