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

Re: Want to process XHTML in my XSL stylesheets.

Subject: Re: Want to process XHTML in my XSL stylesheets.
From: Francis Norton <francis@xxxxxxxxxxx>
Date: Tue, 09 Jul 2002 17:34:57 +0100
norton process name

Michael Kay wrote:


There are some things that happen in a stylesheet that make the analysis
impossible, e.g. use of <xsl:element name="{expr}">. There are many
other things that make the analysis impractical, for example if the
stylesheet does <xsl:apply-templates select="*[position()>2]", you might
have to infer that this can't select a <title> or <subtitle> element
because those can only occur in the first two positions; or you have to
infer that the template rule for match="para[1]" will always be fired
before the one for match="para". In general that requires some quite
powerful analysis.

Yes - I'd assumed that you would simply flag the over-dynamic cases as generating invalid content, but as you say, it's quite possible that there will be cases which in fact are valid but are undecidable by any program of sensible complexity.

It's still very much an open question how much is achievable form static
analysis of a stylesheet, but my suspicion is that in most cases the
only type you can deduce for the result tree is "document".


I'd have thought it would be possible to specify a profile of XSLT for which you can do static structural typing, though your examples so far are impressively daunting...

One reason
for this is that I think most real stylesheets assume things about the
source documents that are not actually explicit in the schema, things
like "all rows will contain the same number of columns", and the
stylesheet will actually fail if these assumptions prove wrong.

This is addressing the slightly different problem of whether the source schema guarantees valid input to a transform, as opposed to whether the transform guarantees output that is valid for the target schema. But of course they are related, in that breaking transform inputs may break the output.

The Software AG XQuery prototype (QuiP)[1] is written in Haskell, and
its developers are very enthusiastic about the language.

[1] http://developer.softwareag.com/tamino/quip/

Thanks - they've helpfully included a link to a Haskell XML library, which give me confidence that there's a sensible path forward if I start exploring this area.

Francis.

--
"Never mind manoeuvre, go straight at 'em." - Admiral Horatio Nelson



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.