Re: [xslt] XSLT conformance issues -- ext[1-3]

[Thomas Broyer <tbroyer ltgt net>]

Le 11/07/01 21:46:12, Thomas Broyer a écrit :
> >   Add a function lookup framework to libxml/XPath similar to the
> >   variable lookup already available.
> >   libxslt then search for extension functions in its global hash table.
> >   typedef xmlXPathFunction
> >           (*xmlXPathFunctionLookupFunc)   (void *ctxt,
> >                                            const xmlChar *name,
> >                                            const xmlChar *ns_uri);
> >   void    xmlXPathRegisterFunctionLookup  (xmlXPathContextPtr ctxt,
> >                                            xmlXPathFunctionLookupFunc
> f,
> >                                            void *funcCtxt);
> 
> Another way is to call the xsltExtInitFunction for each declared prefix
> (even if not declared as extension-element-prefix)
> [NOTE: for each namespace node in the hole stylesheet (cf. also Issue
> ext4), as a top-level element may carry its namespace declaration -- e.g.
> a func:function element may have an xmlns:func declaration, with no
> xmlns:func declaration in the xsl:stylesheet element]

OK, so here is a proposal to close issues ext1 through ext4.

There are three types of "extensions":
 · top-level elements
 · instruction elements
 · functions

Each type has its own registration framework, they are all registered
application-wide.

An extension module consists of these elements and functions and a couple
of functions to allocate specific data (xsltExtInitFunction and
xsltExtShutdownFunction).
[CLOSES: ext1, ext3]

During proprocessing, extension-element-prefixes only builds a list of
extension namespaces attached to the node PreComp data. They are also
automatically added to the list of exclude-result-prefixes.
For each non-XSLT instruction element, the processor checks whether the
element namespace has been declared an extension namespace. If so, it marks
the element as an extension element.
To know if an element is an extension element or a literal result element,
the processor just go through the element's ancestors searching for the
element's namespace URI in the extension-element-prefixes lists.
[CLOSES: ext4]

Just before transformation, the processor calls the xsltExtInitFunction for
each module whose namespace has been declared in xsl:stylesheet (or
ancestor element) to allocate the module's data.
Just before transformation, the processor goes through every top-level
element and calls its xsltTransformFunction if available.
[CLOSES: ext2]

Possible improvements:
 · list of top-level extension elements may be computed during
   preprocessing and stored in the stylesheet (simple linked list)
 · xsltExtInitFunction may be called automatically inside xsltGetExtData
   if there isn't any extData registered for this module.
   This prevents useless allocations in case an extension is never
   instanciated.

EXSLT - Functions specifies an implicit declaration of an
extension-element-prefixes prefix. This issue can be closed within two
ways:
 · during transformation, for each literal result element, check whether
   it has become an extension prefix due to some earlier processing
 · add a framework to preprocess extension elements. An extension
   (top-level or instruction) element is composed of 2 functions:
   one to preprocess it, the other to process it then.
   During preprocessing, the element can modify the
   extension-element-prefixes list, modifications will be available for
   its subtree.

[NOTE: current functions xsltRegisterExtFunction and xsltRegisterExtElement
are context-dependant. They may be kept for compatibility if needed]

I know this totally changes the very-new extension API, I'm sorry, I
misread some part of the spec (particularly the one saying top-level
elements are not "extension elements", in [14.1 Extension ELements])

[NOTE: this is a proposal. It's for a better extension framework only. I
think I can implement EXSLT without it -- processing top-level elements in
xsltExtInitFunction by going through the stylesheet trees, etc. --, it
would just be better/easier if such a framework existed]

Actually, only Issue ext3 is _really_ an issue and MUST be fixed.

Tom.