doc/internals.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
   2 <html>
   3 <head>
   4 <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
   5 <style type="text/css"><!--
   6 TD {font-size: 10pt; font-family: Verdana,Arial,Helvetica}
   7 BODY {font-size: 10pt; font-family: Verdana,Arial,Helvetica; margin-top: 5pt; margin-left: 0pt; margin-right: 0pt}
   8 H1 {font-size: 16pt; font-family: Verdana,Arial,Helvetica}
   9 H2 {font-size: 14pt; font-family: Verdana,Arial,Helvetica}
  10 H3 {font-size: 12pt; font-family: Verdana,Arial,Helvetica}
  11 A:link, A:visited, A:active { text-decoration: underline }
  12 --></style>
  13 <title>Library internals</title>
  14 </head>
  15 <body bgcolor="#8b7765" text="#000000" link="#000000" vlink="#000000">
  16 <table border="0" width="100%" cellpadding="5" cellspacing="0" align="center"><tr>
  17 <td width="100">
  18 <a href="http://www.gnome.org/"><img src="smallfootonly.gif" alt="Gnome Logo"></a><a href="http://www.redhat.com"><img src="redhat.gif" alt="Red Hat Logo"></a>
  19 </td>
  20 <td><table border="0" width="90%" cellpadding="2" cellspacing="0" align="center" bgcolor="#000000"><tr><td><table width="100%" border="0" cellspacing="1" cellpadding="3" bgcolor="#fffacd"><tr><td align="center">
  21 <h1>The XSLT C library for Gnome</h1>
  22 <h2>Library internals</h2>
  23 </td></tr></table></td></tr></table></td>
  24 </tr></table>
  25 <table border="0" cellpadding="4" cellspacing="0" width="100%" align="center"><tr><td bgcolor="#8b7765"><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr>
  26 <td valign="top" width="200" bgcolor="#8b7765"><table border="0" cellspacing="0" cellpadding="1" width="100%" bgcolor="#000000"><tr><td>
  27 <table width="100%" border="0" cellspacing="1" cellpadding="3">
  28 <tr><td colspan="1" bgcolor="#eecfa1" align="center"><center><b>Main Menu</b></center></td></tr>
  29 <tr><td bgcolor="#fffacd"><ul style="margin-left: -2pt">
  30 <li><a href="index.html">Home</a></li>
  31 <li><a href="intro.html">Introduction</a></li>
  32 <li><a href="docs.html">Documentation</a></li>
  33 <li><a href="bugs.html">Reporting bugs and getting help</a></li>
  34 <li><a href="help.html">How to help</a></li>
  35 <li><a href="downloads.html">Downloads</a></li>
  36 <li><a href="news.html">News</a></li>
  37 <li><a href="xsltproc2.html">The xsltproc tool</a></li>
  38 <li><a href="API.html">The programming API</a></li>
  39 <li><a href="internals.html">Library internals</a></li>
  40 <li><a href="extensions.html">Writing extensions</a></li>
  41 <li><a href="contribs.html">Contributions</a></li>
  42 <li>
  43 <a href="xslt.html">flat page</a>, <a href="site.xsl">stylesheet</a>
  44 </li>
  45 </ul></td></tr>
  46 </table>
  47 <table width="100%" border="0" cellspacing="1" cellpadding="3">
  48 <tr><td colspan="1" bgcolor="#eecfa1" align="center"><center><b>Related links</b></center></td></tr>
  49 <tr><td bgcolor="#fffacd"><ul style="margin-left: -2pt">
  50 <li><a href="tutorial/libxslttutorial.html">Tutorial</a></li>
  51 <li><a href="xsltproc.html">Man page for xsltproc</a></li>
  52 <li><a href="http://mail.gnome.org/archives/xslt/">Mail archive</a></li>
  53 <li><a href="http://xmlsoft.org/">XML libxml</a></li>
  54 <li><a href="http://www.cs.unibo.it/~casarini/gdome2/">DOM gdome2</a></li>
  55 <li><a href="ftp://xmlsoft.org/">FTP</a></li>
  56 <li><a href="http://www.fh-frankfurt.de/~igor/projects/libxml/">Windows binaries</a></li>
  57 <li><a href="http://pages.eidosnet.co.uk/~garypen/libxml/">Solaris binaries</a></li>
  58 <li><a href="http://bugzilla.gnome.org/buglist.cgi?product=libxslt">Bug Tracker</a></li>
  59 <li><a href="http://xsldbg.sourceforge.net/">Xsldbg Debugger</a></li>
  60 </ul></td></tr>
  61 </table>
  62 </td></tr></table></td>
  63 <td valign="top" bgcolor="#8b7765"><table border="0" cellspacing="0" cellpadding="1" width="100%"><tr><td><table border="0" cellspacing="0" cellpadding="1" width="100%" bgcolor="#000000"><tr><td><table border="0" cellpadding="3" cellspacing="1" width="100%"><tr><td bgcolor="#fffacd">
  64 <h3>Table  of contents</h3>
  65 <ul>
  66 <li><a href="internals.html#Introducti">Introduction</a></li>
  67 <li><a href="internals.html#Basics">Basics</a></li>
  68 <li><a href="internals.html#Keep">Keep it simple stupid</a></li>
  69 <li><a href="internals.html#libxml">The libxml nodes</a></li>
  70 <li><a href="internals.html#XSLT">The XSLT processing steps</a></li>
  71 <li><a href="internals.html#XSLT1">The XSLT stylesheet compilation</a></li>
  72 <li><a href="internals.html#XSLT2">The XSLT template compilation</a></li>
  73 <li><a href="internals.html#processing">The processing itself</a></li>
  74 <li><a href="internals.html#XPath">XPath expressions compilation</a></li>
  75 <li><a href="internals.html#XPath1">XPath interpretation</a></li>
  76 <li><a href="internals.html#Descriptio">Description of XPath
  77   Objects</a></li>
  78 <li><a href="internals.html#XPath3">XPath functions</a></li>
  79 <li><a href="internals.html#stack">The variables stack frame</a></li>
  80 <li><a href="internals.html#Extension">Extension support</a></li>
  81 <li><a href="internals.html#Futher">Further reading</a></li>
  82 <li><a href="internals.html#TODOs">TODOs</a></li>
  83 </ul>
  84 <h3><a name="Introducti2">Introduction</a></h3>
  85 <p>This document describes the processing of <a href="http://xmlsoft.org/XSLT/">libxslt</a>, the <a href="http://www.w3.org/TR/xslt">XSLT</a> C library developed for the <a href="http://www.gnome.org/">Gnome</a> project.</p>
  86 <p>Note: this documentation is by definition incomplete and I am not good at
  87 spelling, grammar, so patches and suggestions are <a href="mailto:veillard@redhat.com">really welcome</a>.</p>
  88 <h3><a name="Basics1">Basics</a></h3>
  89 <p>XSLT is a transformation language. It takes an input document and a
  90 stylesheet document and generates an output document:</p>
  91 <p align="center"><img src="processing.gif" alt="the XSLT processing model"></p>
  92 <p>Libxslt is written in C. It relies on <a href="http://www.xmlsoft.org/">libxml</a>, the XML C library for Gnome, for
  93 the following operations:</p>
  94 <ul>
  95 <li>parsing files</li>
  96 <li>building the in-memory DOM structure associated with the documents
  97     handled</li>
  98 <li>the XPath implementation</li>
  99 <li>serializing back the result document to XML and HTML. (Text is handled
 100     directly.)</li>
 101 </ul>
 102 <h3><a name="Keep1">Keep it simple stupid</a></h3>
 103 <p>Libxslt is not very specialized. It is built under the assumption that all
 104 nodes from the source and output document can fit in the virtual memory of
 105 the system. There is a big trade-off there. It is fine for reasonably sized
 106 documents but may not be suitable for large sets of data. The gain is that it
 107 can be used in a relatively versatile way. The input or output may never be
 108 serialized, but the size of documents it can handle are limited by the size
 109 of the memory available.</p>
 110 <p>More specialized memory handling approaches are possible, like building
 111 the input tree from a serialization progressively as it is consumed,
 112 factoring repetitive patterns, or even on-the-fly generation of the output as
 113 the input is parsed but it is possible only for a limited subset of the
 114 stylesheets. In general the implementation of libxslt follows the following
 115 pattern:</p>
 116 <ul>
 117 <li>KISS (keep it simple stupid)</li>
 118 <li>when there is a clear bottleneck optimize on top of this simple
 119     framework and refine only as much as is needed to reach the expected
 120     result</li>
 121 </ul>
 122 <p>The result is not that bad, clearly one can do a better job but more
 123 specialized too. Most optimization like building the tree on-demand would
 124 need serious changes to the libxml XPath framework. An easy step would be to
 125 serialize the output directly (or call a set of SAX-like output handler to
 126 keep this a flexible interface) and hence avoid the memory consumption of the
 127 result.</p>
 128 <h3><a name="libxml">The libxml nodes</a></h3>
 129 <p>DOM-like trees, as used and generated by libxml and libxslt, are
 130 relatively complex. Most node types follow the given structure except a few
 131 variations depending on the node type:</p>
 132 <p align="center"><img src="node.gif" alt="description of a libxml node"></p>
 133 <p>Nodes carry a <strong>name</strong> and the node <strong>type</strong>
 134 indicates the kind of node it represents, the most common ones are:</p>
 135 <ul>
 136 <li>document nodes</li>
 137 <li>element nodes</li>
 138 <li>text nodes</li>
 139 </ul>
 140 <p>For the XSLT processing, entity nodes should not be generated (i.e. they
 141 should be replaced by their content). Most nodes also contains the following
 142 &quot;navigation&quot; informations:</p>
 143 <ul>
 144 <li>the containing <strong>doc</strong>ument</li>
 145 <li>the <strong>parent</strong> node</li>
 146 <li>the first <strong>children</strong> node</li>
 147 <li>the <strong>last</strong> children node</li>
 148 <li>the <strong>prev</strong>ious sibling</li>
 149 <li>the following sibling (<strong>next</strong>)</li>
 150 </ul>
 151 <p>Elements nodes carries the list of attributes in the properties, an
 152 attribute itself holds the navigation pointers and the children list (the
 153 attribute value is not represented as a simple string to allow usage of
 154 entities references).</p>
 155 <p>The <strong>ns</strong> points to the namespace declaration for the
 156 namespace associated to the node, <strong>nsDef</strong> is the linked list
 157 of namespace declaration present on element nodes.</p>
 158 <p>Most nodes also carry an <strong>_private</strong> pointer which can be
 159 used by the application to hold specific data on this node.</p>
 160 <h3><a name="XSLT">The XSLT processing steps</a></h3>
 161 <p>There are a few steps which are clearly decoupled at the interface
 162 level:</p>
 163 <ol>
 164 <li>parse the stylesheet and generate a DOM tree</li>
 165 <li>take the stylesheet tree and build a compiled version of it (the
 166     compilation phase)</li>
 167 <li>take the input and generate a DOM tree</li>
 168 <li>process the stylesheet against the input tree and generate an output
 169     tree</li>
 170 <li>serialize the output tree</li>
 171 </ol>
 172 <p>A few things should be noted here:</p>
 173 <ul>
 174 <li>the steps 1/ 3/ and 5/ are optional</li>
 175 <li>the stylesheet obtained at 2/ can be reused by multiple processing 4/
 176     (and this should also work in threaded programs)</li>
 177 <li>the tree provided in 2/ should never be freed using xmlFreeDoc, but by
 178     freeing the stylesheet.</li>
 179 <li>the input tree 4/ is not modified except the _private field which may
 180     be used for labelling keys if used by the stylesheet</li>
 181 </ul>
 182 <h3><a name="XSLT1">The XSLT stylesheet compilation</a></h3>
 183 <p>This is the second step described. It takes a stylesheet tree, and
 184 &quot;compiles&quot; it. This associates to each node a structure stored in the
 185 _private field and containing information computed in the stylesheet:</p>
 186 <p align="center"><img src="stylesheet.gif" alt="a compiled XSLT stylesheet"></p>
 187 <p>One xsltStylesheet structure is generated per document parsed for the
 188 stylesheet. XSLT documents allow includes and imports of other documents,
 189 imports are stored in the <strong>imports</strong> list (hence keeping the
 190 tree hierarchy of includes which is very important for a proper XSLT
 191 processing model) and includes are stored in the <strong>doclist</strong>
 192 list. An imported stylesheet has a parent link to allow browsing of the
 193 tree.</p>
 194 <p>The DOM tree associated to the document is stored in <strong>doc</strong>.
 195 It is preprocessed to remove ignorable empty nodes and all the nodes in the
 196 XSLT namespace are subject to precomputing. This usually consist of
 197 extracting all the context information from the context tree (attributes,
 198 namespaces, XPath expressions), and storing them in an xsltStylePreComp
 199 structure associated to the <strong>_private</strong> field of the node.</p>
 200 <p>A couple of notable exceptions to this are XSLT template nodes (more on
 201 this later) and attribute value templates. If they are actually templates,
 202 the value cannot be computed at compilation time. (Some preprocessing could
 203 be done like isolation and preparsing of the XPath subexpressions but it's
 204 not done, yet.)</p>
 205 <p>The xsltStylePreComp structure also allows storing of the precompiled form
 206 of an XPath expression that can be associated to an XSLT element (more on
 207 this later).</p>
 208 <h3><a name="XSLT2">The XSLT template compilation</a></h3>
 209 <p>A proper handling of templates lookup is one of the keys of fast XSLT
 210 processing. (Given a node in the source document this is the process of
 211 finding which templates should be applied to this node.) Libxslt follows the
 212 hint suggested in the <a href="http://www.w3.org/TR/xslt#patterns">5.2
 213 Patterns</a> section of the XSLT Recommendation, i.e. it doesn't evaluate it
 214 as an XPath expression but tokenizes it and compiles it as a set of rules to
 215 be evaluated on a candidate node. There usually is an indication of the node
 216 name in the last step of this evaluation and this is used as a key check for
 217 the match. As a result libxslt builds a relatively more complex set of
 218 structures for the templates:</p>
 219 <p align="center"><img src="templates.gif" alt="The templates related structure"></p>
 220 <p>Let's describe a bit more closely what is built. First the xsltStylesheet
 221 structure holds a pointer to the template hash table. All the XSLT patterns
 222 compiled in this stylesheet are indexed by the value of the the target
 223 element (or attribute, pi ...) name, so when a element or an attribute &quot;foo&quot;
 224 needs to be processed the lookup is done using the name as a key.</p>
 225 <p>Each of the patterns is compiled into an xsltCompMatch structure. It holds
 226 the set of rules based on the tokenization of the pattern stored in reverse
 227 order (matching is easier this way). It also holds some information about the
 228 previous matches used to speed up the process when one iterates over a set of
 229 siblings. (This optimization may be defeated by trashing when running
 230 threaded computation, it's unclear that this is a big deal in practice.)
 231 Predicate expressions are not compiled at this stage, they may be at run-time
 232 if needed, but in this case they are compiled as full XPath expressions (the
 233 use of some fixed predicate can probably be optimized, they are not yet).</p>
 234 <p>The xsltCompMatch are then stored in the hash table, the clash list is
 235 itself sorted by priority of the template to implement &quot;naturally&quot; the XSLT
 236 priority rules.</p>
 237 <p>Associated to the compiled pattern is the xsltTemplate itself containing
 238 the information required for the processing of the pattern including, of
 239 course, a pointer to the list of elements used for building the pattern
 240 result.</p>
 241 <p>Last but not least a number of patterns do not fit in the hash table
 242 because they are not associated to a name, this is the case for patterns
 243 applying to the root, any element, any attributes, text nodes, pi nodes, keys
 244 etc. Those are stored independently in the stylesheet structure as separate
 245 linked lists of xsltCompMatch.</p>
 246 <h3><a name="processing">The processing itself</a></h3>
 247 <p>The processing is defined by the XSLT specification (the basis of the
 248 algorithm is explained in <a href="http://www.w3.org/TR/xslt#section-Introduction">the Introduction</a>
 249 section). Basically it works by taking the root of the input document and
 250 applying the following algorithm:</p>
 251 <ol>
 252 <li>Finding the template applying to it. This is a lookup in the template
 253     hash table, walking the hash list until the node satisfies all the steps
 254     of the pattern, then checking the appropriate(s) global templates to see
 255     if there isn't a higher priority rule to apply</li>
 256 <li>If there is no template, apply the default rule (recurse on the
 257     children)</li>
 258 <li>else walk the content list of the selected templates, for each of them:
 259     <ul>
 260 <li>if the node is in the XSLT namespace then the node has a _private
 261         field pointing to the preprocessed values, jump to the specific
 262       code</li>
 263 <li>if the node is in an extension namespace, look up the associated
 264         behavior</li>
 265 <li>otherwise copy the node.</li>
 266 </ul>
 267 <p>The closure is usually done through the XSLT
 268     <strong>apply-templates</strong> construct recursing by applying the
 269     adequate template on the input node children or on the result of an
 270     associated XPath selection lookup.</p>
 271 </li>
 272 </ol>
 273 <p>Note that large parts of the input tree may not be processed by a given
 274 stylesheet and that on the opposite some may be processed multiple times.
 275 (This often is the case when a Table of Contents is built).</p>
 276 <p>The module <code>transform.c</code> is the one implementing most of this
 277 logic. <strong>xsltApplyStylesheet()</strong> is the entry point, it
 278 allocates an xsltTransformContext containing the following:</p>
 279 <ul>
 280 <li>a pointer to the stylesheet being processed</li>
 281 <li>a stack of templates</li>
 282 <li>a stack of variables and parameters</li>
 283 <li>an XPath context</li>
 284 <li>the template mode</li>
 285 <li>current document</li>
 286 <li>current input node</li>
 287 <li>current selected node list</li>
 288 <li>the current insertion points in the output document</li>
 289 <li>a couple of hash tables for extension elements and functions</li>
 290 </ul>
 291 <p>Then a new document gets allocated (HTML or XML depending on the type of
 292 output), the user parameters and global variables and parameters are
 293 evaluated. Then <strong>xsltProcessOneNode()</strong> which implements the
 294 1-2-3 algorithm is called on the root element of the input. Step 1/ is
 295 implemented by calling <strong>xsltGetTemplate()</strong>, step 2/ is
 296 implemented by <strong>xsltDefaultProcessOneNode()</strong> and step 3/ is
 297 implemented by <strong>xsltApplyOneTemplate()</strong>.</p>
 298 <h3><a name="XPath">XPath expression compilation</a></h3>
 299 <p>The XPath support is actually implemented in the libxml module (where it
 300 is reused by the XPointer implementation). XPath is a relatively classic
 301 expression language. The only uncommon feature is that it is working on XML
 302 trees and hence has specific syntax and types to handle them.</p>
 303 <p>XPath expressions are compiled using <strong>xmlXPathCompile()</strong>.
 304 It will take an expression string in input and generate a structure
 305 containing the parsed expression tree, for example the expression:</p>
 306 <pre>/doc/chapter[title='Introduction']</pre>
 307 <p>will be compiled as</p>
 308 <pre>Compiled Expression : 10 elements
 309   SORT
 310     COLLECT  'child' 'name' 'node' chapter
 311       COLLECT  'child' 'name' 'node' doc
 312         ROOT
 313       PREDICATE
 314         SORT
 315           EQUAL =
 316             COLLECT  'child' 'name' 'node' title
 317               NODE
 318             ELEM Object is a string : Introduction
 319               COLLECT  'child' 'name' 'node' title
 320                 NODE</pre>
 321 <p>This can be tested using the  <code>testXPath</code>  command (in the
 322 libxml codebase) using the <code>--tree</code> option.</p>
 323 <p>Again, the KISS approach is used. No optimization is done. This could be
 324 an interesting thing to add. <a href="http://www-106.ibm.com/developerworks/library/x-xslt2/?dwzone=x?open&amp;l=132%2ct=gr%2c+p=saxon">Michael
 325 Kay describes</a> a lot of possible and interesting optimizations done in
 326 Saxon which would be possible at this level. I'm unsure they would provide
 327 much gain since the expressions tends to be relatively simple in general and
 328 stylesheets are still hand generated. Optimizations at the interpretation
 329 sounds likely to be more efficient.</p>
 330 <h3><a name="XPath1">XPath interpretation</a></h3>
 331 <p>The interpreter is implemented by <strong>xmlXPathCompiledEval()</strong>
 332 which is the front-end to <strong>xmlXPathCompOpEval()</strong> the function
 333 implementing the evaluation of the expression tree. This evaluation follows
 334 the KISS approach again. It's recursive and calls
 335 <strong>xmlXPathNodeCollectAndTest()</strong> to collect nodes set when
 336 evaluating a <code>COLLECT</code> node.</p>
 337 <p>An evaluation is done within the framework of an XPath context stored in
 338 an <strong>xmlXPathContext</strong> structure, in the framework of a
 339 transformation the context is maintained within the XSLT context. Its content
 340 follows the requirements from the XPath specification:</p>
 341 <ul>
 342 <li>the current document</li>
 343 <li>the current node</li>
 344 <li>a hash table of defined variables (but not used by XSLT)</li>
 345 <li>a hash table of defined functions</li>
 346 <li>the proximity position (the place of the node in the current node
 347   list)</li>
 348 <li>the context size (the size of the current node list)</li>
 349 <li>the array of namespace declarations in scope (there also is a namespace
 350     hash table but it is not used in the XSLT transformation).</li>
 351 </ul>
 352 <p>For the purpose of XSLT an <strong>extra</strong> pointer has been added
 353 allowing to retrieve the XSLT transformation context. When an XPath
 354 evaluation is about to be performed, an XPath parser context is allocated
 355 containing and XPath object stack (this is actually an XPath evaluation
 356 context, this is a remain of the time where there was no separate parsing and
 357 evaluation phase in the XPath implementation). Here is an overview of the set
 358 of contexts associated to an XPath evaluation within an XSLT
 359 transformation:</p>
 360 <p align="center"><img src="contexts.gif" alt="The set of contexts associated "></p>
 361 <p>Clearly this is a bit too complex and confusing and should be refactored
 362 at the next set of binary incompatible releases of libxml. For example the
 363 xmlXPathCtxt has a lot of unused parts and should probably be merged with
 364 xmlXPathParserCtxt.</p>
 365 <h3><a name="Descriptio">Description of XPath Objects</a></h3>
 366 <p>An XPath expression manipulates XPath objects. XPath defines the default
 367 types boolean, numbers, strings and node sets. XSLT adds the result tree
 368 fragment type which is basically an unmodifiable node set.</p>
 369 <p>Implementation-wise, libxml follows again a KISS approach, the
 370 xmlXPathObject is a structure containing a type description and the various
 371 possibilities. (Using an enum could have gained some bytes.) In the case of
 372 node sets (or result tree fragments), it points to a separate xmlNodeSet
 373 object which contains the list of pointers to the document nodes:</p>
 374 <p align="center"><img src="object.gif" alt="An Node set object pointing to "></p>
 375 <p>The <a href="http://xmlsoft.org/html/libxml-xpath.html">XPath API</a> (and
 376 its <a href="http://xmlsoft.org/html/libxml-xpathinternals.html">'internal'
 377 part</a>) includes a number of functions to create, copy, compare, convert or
 378 free XPath objects.</p>
 379 <h3><a name="XPath3">XPath functions</a></h3>
 380 <p>All the XPath functions available to the interpreter are registered in the
 381 function hash table linked from the XPath context. They all share the same
 382 signature:</p>
 383 <pre>void xmlXPathFunc (xmlXPathParserContextPtr ctxt, int nargs);</pre>
 384 <p>The first argument is the XPath interpretation context, holding the
 385 interpretation stack. The second argument defines the number of objects
 386 passed on the stack for the function to consume (last argument is on top of
 387 the stack).</p>
 388 <p>Basically an XPath function does the following:</p>
 389 <ul>
 390 <li>check <code>nargs</code> for proper handling of errors or functions
 391     with variable numbers of parameters</li>
 392 <li>pop the parameters from the stack using <code>obj =
 393     valuePop(ctxt);</code>
 394 </li>
 395 <li>do the function specific computation</li>
 396 <li>push the result parameter on the stack using <code>valuePush(ctxt,
 397     res);</code>
 398 </li>
 399 <li>free up the input parameters with
 400   <code>xmlXPathFreeObject(obj);</code>
 401 </li>
 402 <li>return</li>
 403 </ul>
 404 <p>Sometime the work can be done directly by modifying in-situ the top object
 405 on the stack <code>ctxt-&gt;value</code>.</p>
 406 <h3><a name="stack">The XSLT variables stack frame</a></h3>
 407 <p>Not to be confused with XPath object stack, this stack holds the XSLT
 408 variables and parameters as they are defined through the recursive calls of
 409 call-template, apply-templates and default templates. This is used to define
 410 the scope of variables being called.</p>
 411 <p>This part seems to be the most urgent attention right now, first it is
 412 done in a very inefficient way since the location of the variables and
 413 parameters within the stylesheet tree is still done at run time (it really
 414 should be done statically at compile time), and I am still unsure that my
 415 understanding of the template variables and parameter scope is actually
 416 right.</p>
 417 <p>This part of the documentation is still to be written once this part of
 418 the code will be stable. <span style="background-color: #FF0000">TODO</span>
 419 </p>
 420 <h3><a name="Extension">Extension support</a></h3>
 421 <p>There is a separate document explaining <a href="extensions.html">how the
 422 extension support works</a>.</p>
 423 <h3><a name="Futher">Further reading</a></h3>
 424 <p>Michael Kay wrote <a href="http://www-106.ibm.com/developerworks/library/x-xslt2/?dwzone=x?open&amp;l=132%2ct=gr%2c+p=saxon">a
 425 really interesting article on Saxon internals</a> and the work he did on
 426 performance issues. I wishes I had read it before starting libxslt design (I
 427 would probably have avoided a few mistakes and progressed faster). A lot of
 428 the ideas in his papers should be implemented or at least tried in
 429 libxslt.</p>
 430 <p>The <a href="http://xmlsoft.org/">libxml documentation</a>, especially <a href="http://xmlsoft.org/xmlio.html">the I/O interfaces</a> and the <a href="http://xmlsoft.org/xmlmem.html">memory management</a>.</p>
 431 <h3><a name="TODOs">TODOs</a></h3>
 432 <p>redesign the XSLT stack frame handling. Far too much work is done at
 433 execution time. Similarly for the attribute value templates handling, at
 434 least the embedded subexpressions ought to be precompiled.</p>
 435 <p>Allow output to be saved to a SAX like output (this notion of SAX like API
 436 for output should be added directly to libxml).</p>
 437 <p>Implement and test some of the optimization explained by Michael Kay
 438 especially:</p>
 439 <ul>
 440 <li>static slot allocation on the stack frame</li>
 441 <li>specific boolean interpretation of an XPath expression</li>
 442 <li>some of the sorting optimization</li>
 443 <li>Lazy evaluation of location path. (this may require more changes but
 444     sounds really interesting. XT does this too.)</li>
 445 <li>Optimization of an expression tree (This could be done as a completely
 446     independent module.)</li>
 447 </ul>
 448 <p>
 449 <p>Error reporting, there is a lot of case where the XSLT specification
 450 specify that a given construct is an error are not checked adequately by
 451 libxslt. Basically one should do a complete pass on the XSLT spec again and
 452 add all tests to the stylesheet compilation. Using the DTD provided in the
 453 appendix and making direct checks using the libxml validation API sounds a
 454 good idea too (though one should take care of not raising errors for
 455 elements/attributes in different namespaces).</p>
 456 <p>Double check all the places where the stylesheet compiled form might be
 457 modified at run time (extra removal of blanks nodes, hint on the
 458 xsltCompMatch).</p>
 459 <p>
 460 <p><a href="mailto:daniel@veillard.com">Daniel Veillard</a></p>
 461 </td></tr></table></td></tr></table></td></tr></table></td>
 462 </tr></table></td></tr></table>
 463 </body>
 464 </html>