Re: [xsl] XSLT 2.0 processor signalling error, for type errors

Subject: Re: [xsl] XSLT 2.0 processor signalling error, for type errors
From: "Mukul Gandhi" <gandhi.mukul@xxxxxxxxx>
Date: Wed, 8 Oct 2008 20:30:19 +0530
Thanks, Mike for the insightful thoughts ...

On Wed, Oct 8, 2008 at 8:05 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>>
>> In case of Saxon, would you say that there is some
>> intermediate representation? I think, the user (or,
>> programmer) has the view that he/she is just running a XSLT
>> program in one pass.
>
> If you look at the various APIs - including the JAXP API, it's clear that
> there is one operation that creates a Templates object, and another
> operation that uses the Templates object (repeatedly, and in multiple
> threads, if you wish) to do a transformation. The Templates object is the
> "compiled" stylesheet. In Saxon this is a heavily optimized expression tree
> rather than a sequence of instructions, but it's conceptually the same.
>
> (Saxon-SA in the case of XQuery also allows you to generate Java code from
> the expression tree, in which case the compiled representation of the query
> is a Java program.)
>>
>> I might guess, that prior to creation of the result XDM tree
>> it's compilation. Does XSLT 2.0 spec define compilation and
>> runtime phases for XSLT?
>>
> Not in so many words, but the distinction is there in the way error handling
> is specified, in the distinction between the static and dynamic context, and
> in facilities like use-when.
>
> The XPath 2.0 spec includes a processing model that makes a more explicit
> distinction. It refers to the two phases as "static analysis" and "dynamic
> evaluation". The term "compile" is deliberately avoided as it could be taken
> to prejudge implementation strategies. The output of the analysis phase is
> called an "operation tree", but there's nothing that says it needs to really
> be a tree.

>
> Michael Kay
> http://www.saxonica.com/



-- 
Regards,
Mukul Gandhi

Current Thread