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

RE: XSLT processor internals (was RE: Another XML parsing idea

• To: Michael Kay <mike@s...>, 'Pete Cordell' <petexmldev@t...>, xml-dev@l...
• Subject: RE: XSLT processor internals (was RE: Another XML parsing idea?)
• From: Mukul Gandhi <mukul_gandhi@y...>
• 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@s...> 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 [expletive deleted] 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 

• Prev by Date: RE: XSLT processor internals (was RE: Another XML parsing idea?)
• Next by Date: RE: Interesting pair of comments (was Re: Schema Experience Workshop minutes online)
• Previous by thread: RE: XSLT processor internals (was RE: Another XML parsing idea?)
• Index(es):
  • Date
  • Thread