xsl-list
[Top] [All Lists]

Re: Request for XSLT2.0 / XML Schema triples

2005-11-28 16:41:27
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


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--