RE: [xsl] Debugging XSLT

Subject: RE: [xsl] Debugging XSLT
From: David Tolpin <dvd@xxxxxxxxxxxxxx>
Date: Wed, 4 Feb 2004 10:10:03 +0400 (AMT)
> From owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx  Wed Feb  4 03:11:06 2004
> From: "Michael Kay" <mhk@xxxxxxxxx>
> To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
> Subject: RE: [xsl] Debugging XSLT
> Date: Tue, 3 Feb 2004 22:53:00 -0000
> Content-Type: text/plain;
> 	charset="us-ascii"
>
> > And by no means, in my opinion, should this debugging 
> > facility be a part of the language.
>
> The debugging facility is not part of the language. What the language
> does is to enable a stylesheet to make assertions about its input and
> output. It's normal good software engineering that programs should
> declare their expectations about their input and output. Without such
> assertions, there is no bug if the expectations are not satisfied, and
> therefore no debugging is possible.

There are tools to analyze data in XSLT; they are XPath predicates.
They are enough to make assertions about a program's input and output
within the model of the language.

XSLT is not a Schema-based language, it is not XDuce 
(http://xduce.sourceforge.net/), XML document types are not a 
part of the language. Mechanically fitting schema-based assertions,
be it XML Schema, Relax NG or any other schema language, into XSLT
is wrong. Either XSLT must have XML types and build the assertions
upon them, or it should refrain from doing so and limit itself to
things semantically inherent to the language.

Instead of enabling one particular schema language (and the approach
described in the working draft is tightly dependent on XML Schema,
it is not as well suitable (and in some cases not suitable at all)
for other schema languages) to be hooked into the transformation
language to provide one particular kind of assertion, without any
provision in the language to ensure that the data is integral (valid)
before the assertion fails; the language could have mechanisms for
interaction with other processing facilities.

An approach could be a separate namespace for augmenting the result
with processing information; I do not insist on this approach; I am
just trying to explain my concern.

I understand it is convenient; at least, some people think so.
Syntax coloring is convenient too. Why syntax coloring is not
included into XSLT 2.0 specification, at least as an optional feature?
It aids authoring and debugging.

Well, I hope I know the answer. But XML Schema based fragment validation
inside XSLT is exactly on the same level as syntax coloring.

David Tolpin
http://davidashen.net/

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


Current Thread