[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 Carlisle <davidc@xxxxxxxxx>
Date: Wed, 4 Feb 2004 13:07:41 GMT
xslt validating a temporary tree
> > 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.
> 
> How would I use XPath to assert that my stylesheet is intended to
> produce valid XHTML? Since a schema for XHTML already exists, isn't it
> rather simpler just to refer to it?

I think that this aspect of adding validation to xslt is rather
unfortunate. If this were the only (or even main) reason for adding it I
think it would be much better to do as in xslt1 and validate using an
external validator afterwards.

It leads to ureasonable expectations. In an early xml-dev discussion on
the benefits of inflicting schema typing on xslt/xquer a member of the
Xquery WG stated that it would be a benefit to be able to _statically_
type the transformations to know they produce valid results given valid
input. That would be a benefit if it were not so clearly impossible,
the chance of being able to statically giving that assurance on any non
trivial transformation is nil.

However "validation" in the sense of XSD does not just validate a
document it in in fact a complex transformation transforming one tree of
string valued nodes into another of nodes with typed values. Since XSLT2
can then access those typed values, being able to "validate" a temporary
tree is not just a simple matter of documenting expectations and raising
an error if expectations are not met, it may be an important functional
part of the transformation that is not really feasible using other
facilities in the language.

So given the rest of the XSLT2/Xpath model I do not think that
"validation" is an aspect that can easily be removed.


Having said that, I do believe that XPath would be much better with only
the schema types specified in "Basic XSLT processor" and that the
non-basic XSLT2 would be better not to be specified at all.

XSLT2-basic is essentially XSLT1 plus some much needed features (regexp,
grouping, xx:node-set())

It also unfortunately has Xpath2 which it has to be said is still a
prime example of what happens if you take a small, even elegant,
language and then form a large committee, many of them who are happy to
admit never having used the language before, to specify a new version of
the language....


David


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

 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.