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

Re: Request for XSLT2.0 / XML Schema triples

Subject: Re: Request for XSLT2.0 / XML Schema triples
From: Soren Kuula <dongfang@xxxxxxxxxxx>
Date: Tue, 29 Nov 2005 00:41:27 +0100
goat template
Dimitre Novatchev wrote:

Hi Soren,

Having public access to your analyser will be very useful.

It seems to be a kind of type-inference engine. I wonder whether
Michael Kay is not already doing something like this (of course I
can't know as I've never tried his SA Saxon).


It isn't really; it works by ... aargh do you expect me to KNOW that? :) Well, for each template rule, it can determine with good accuracy a set of node types that may be context nodes at some instantiation (is it called that? Execution. Invocation. Whateveration) of the template rule. For each type, is can compute the set of template rules that are invoked at any apply-templates (or other recursion instruction). Then, we get a context flow graph (looks like a control flow graph), and by some black magic (let me write the report first, OK?), a summary graph is constructed, describing a tight superlanguage of the regular tree language that the transform may generate, given that its input is valid by the input schema. Then, the summary graph is (more black magic) validated against the output schema.
Not much type talk involved.


It is interesting whether such kind of type inference can be done
statically, or if it generally requires dynamic analysis.

One example is:

<xsl:function name="f:foo" as="item()*">

<!-- Code, producing *always* a non-empty sequence of elements -->

</xsl:function>


Will your analyser confirm the fact that f:foo() is producing element()+ ?


No. I have not emphasized on functions (they are so inherently hard to analyze generally that there it little point in even just trying). It will just be translated to a different function, defined as spewing out completely unknown stuff all the time.

But the algorithm WILL detect this (among a lot of other things):

<xsl:template match="/">
<cow>
<xsl:apply-templates/>
</cow>
</xsl:template>

<xsl:template match="foo | bar">
<goat>
</goat>
<xsl:apply-templates/>
</xsl:template>

-- if the input schema declares foo to always have one bar child (or descendant, for that sake), and the output schema demands that a cow element has an even number of goat children (<repeat><sequence><element ref=goat><element ref=goat></></>), then validation will succeed!
- if the the input schema declares foo to maybe have one bar child, and the output schema demands that a cow element has an even number of goat children (<repeat><sequence><element ref=goat><element ref=goat></></>), then validation will fail!
- if the the input schema declares foo to maybe have one bar child, and the output schema demands that a cow element has an odd number of goat children (<element ref=goat><repeat><sequence><element ref=goat/><element ref=goat/></></>), then validation will fail!


- So I'm more into structure than types!

Soren

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.