OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: XSLT processor internals (was RE: [xml-dev] Another XML parsing idea

[ 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.


--- 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 


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS