[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Debugging XSLT

Subject: RE: Debugging XSLT
From: David Tolpin <dvd@xxxxxxxxxxxxxx>
Date: Wed, 4 Feb 2004 10:10:03 +0400 (AMT)
namespace is not a schema
> From owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx  Wed Feb  4 03:11:06 2004
> From: "Michael Kay" <mhk@xxxxxxxxx>
> To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
> Subject: RE:  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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.