[
Lists Home |
Date Index |
Thread Index
]
- To: Michael Kay <mike@saxonica.com>, 'Pete Cordell' <petexmldev@tech-know-ware.com>, xml-dev@lists.xml.org
- Subject: RE: XSLT processor internals (was RE: [xml-dev] Another XML parsing idea?)
- From: Mukul Gandhi <mukul_gandhi@yahoo.com>
- Date: Thu, 14 Jul 2005 16:25:06 -0700 (PDT)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=W/TioZv5wvH+HdB0D2IzQCMkiKrnlsPUT+I4T59ql0/L4G6Ov/8F6KGzAP3jDBByjl1qHXjL1/hnaZvYFR+Fmn9qwntnax0TXwxNtHQgD4SnWb79FNOwu4NPo/lx/xAppvh405IScVqKnYN2/yiCMxTV5Sh5qb+vHAAnnFkrCQE= ;
Thank you Mike for an enlightening description. I'll
study the source code of Saxon as I get time.
Presently I am happy using Saxon! Its very nice.
Regards,
Mukul
--- Michael Kay <mike@saxonica.com> wrote:
> > I start an unrelated topic. How do you implement
> > xsl:template name="something" and its required
> > instruction xsl:call-template in the XSLT
> processor.
> > i.e. what kind of data structures do you use in
> Java
> > and what kind of control flow takes place. Am just
> > curious since many days..
>
> Depends greatly on the processor. Saxon compiles
> each template or function
> into an abstract syntax tree, which is then heavily
> re-arranged by the
> optimizer and type-checker, and is then executed
> interpretively at run-time.
> A call-template instruction is a node in this tree,
> containing a pointer to
> the tree representing the template to be called.
> Template names aren't used
> at run-time, they are fully resolved at compile
> time.
>
> You asked about control flow. In Saxon 6.x, and
> probably in most XSLT 1.0
> processors, the XSLT and XPath engines were very
> separate. In 8.x they have
> become much more integrated, probably reflecting the
> influence of XQuery.
> However Saxon still has two modes of execution
> internally, pull and push:
> expressions such as path expressions are usually
> evaluated by a stack of
> iterators sucking data in a pipeline from the source
> document, while element
> and attribute construction instructions are usually
> evaluated by means of a
> push pipeline pushing SAX-like events out to the
> serializer (or the result
> tree builder if the user requests one). Control
> instructions such as xsl:if
> and xsl:call-template can be evaluated in either
> mode, depending on where
> they appear. There's also a fairly experimental
> capability to execute
> element constructors in pull mode, leading to lazy
> tree construction, so
> parts of a temporary tree that aren't ever
> referenced don't actually get
> built.
>
> If you're interested in understanding such things it
> would be instructive to
> read the source code of a processor such as Saxon.
> It's probably a bit
> daunting at first, but you'll find it interesting.
>
> Michael Kay
> http://www.saxonica.com/
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
