Re: [xslt] XSLT conformance issues -- top-level elements

[Thomas Broyer <tbroyer ltgt net>]

Le 12/07/01 14:21:05, Daniel Veillard a écrit :
> On Thu, Jul 12, 2001 at 05:17:33AM +0200, Thomas Broyer wrote:
> [ Sorry I'm on the road. Didn't had time to read most of what you wrote ]

And I'm sorry to write so much ;o)

> > There are three types of "extensions":
> >  · top-level elements
> >  · instruction elements
> >  · functions
> 
>   Sorry no top level elements are not part of XSLT extension framework
> and I'm unsure why they are needed . Relying on those to be processed
> is not part of the standard and unless I get a proof it is indeed needed
> we should not make specific provision for them.

Well, my first view of EXSLT - Functions implementation was to process
top-level func:function elements (nearly) like any other element. These
elements register a generic callback function in the XPath context attached
to the name of the defined function, and the func:function node in the
module data.

Without top-level elements processing, my ExtInit function needs to go
through all top-level elements -- even in imported and included stylesheet,
taking care of import precedence, etc. -- to do this registration.

The problem here is that the ExtInit function is called only for
extension-element-prefixes. The func:function element is a top-level
element so doesn't need its prefix to be a extension-element-prefix in
order to be processed.
=> the func prefix doesn't need to be declared an extension prefix for the
func:function element to be processed and register the functions into the
XPath context.

Let's take a little, simple example:
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:func="http://exslt.org/functions">
    xmlns:my="foobar:my"

<func:function name="my:test">
  <func:return select="'OK'"/>
</func:function>

<xsl:template match="/">
  <xsl:value-of select="my:test()"/>
</xsl:template>

</xsl:stylesheet>

This is a totally "valid" stylesheet using the EXSLT - Functions module,
and it works with SAXON for example.

For the my:test() function to be recognized, it must be registered in the
XPath context, so the func:function must have been processed, and the EXSLT
- Functions module initialized.
 => there's no need for extension-element-prefixes="func" according to
    the XSLT spec (extension-element-prefixes only applies to
    instructions)
 => thus the module isn't initialized, and no processing can be done
 => libxslt ignores the func:function element, it isn't processed
With the actual libxslt framework, there's no way to solve the problem (I
currently test the EXSLT - Functions module declaring the func prefix as an
extension prefix and putting the func:function element inside a template)

Solutions are:
 · call the ExtInit function for each namespace declaration.
   extension-element-prefixes is just an indication for the processor to
   treat instructions belonging to these namespaces as extension elements
   The ExtInit function can do the preprocessing.
 · or process each top-level element. Top-level elements are registered
   application-wide, the processor search, for each top-level element, if
   it is an "extension element". Note the above point must be performed
   as weel, or another solution provided to initialize the module as soon
   as one of its element has been found.
 · or function lookup in XPath must be extended. The first point is also
   needed for the module to registers its function lookup function.
   For EXSLT - Functions, the function lookup function would go through
   top-level elements looking for func:function with the appropriate
   name attribute.

So one point is sure: the ExtInit function must be called even if the
prefix isn't an extension-element-prefix. And this also solves the problem
of extension functions (which do not need their prefix to be declared an
extension prefix either)

Then, we need to choose whether top-level elements are processed
"automatically" or this is left to the module.
In the second case, modules will need to deal with imported and included
stylesheets and import precedence. The processor may list all the top-level
elements in a single place (the xsltStylesheet) to make it easier for
modules to go through them.

> one point is sure the existing API must be preserved now.

Yes. The above proposal tries to deal with it. Calling ExtInit at namespace
declaration should do the trick, but a separate top-level and instruction
elements registration framework MUST be done for element-available() to be
conformant.

<_private>
You'll notice that, as always, I started with an "idealistic view" and made
it evolve to a more pragmatic one ;o)
Hey, I try to make my best not to break existing things! ;o)
</_private>

Tom.