RE: [xsl] Re: [exslt] Re: [xsl] Importing compiled stylesheets

["Michael Kay" <mike@xxxxxxxxxxxx>]

It's worth reading up how modules in XQuery work - both in the query
language book and the formal semantics. XQuery modules are designed for
separate compilation, and the design tries (not always successfully) to
address the problems caused by the fact that the calling module and called
module might have imported different schemas.

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: Dimitre Novatchev [mailto:dnovatchev@xxxxxxxxx] 
> Sent: 13 June 2005 22:00
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [xsl] Re: [exslt] Re: [xsl] Importing compiled 
> stylesheets
> 
> On 6/13/05, David Carlisle <davidc@xxxxxxxxx> wrote:
> > 
> >  A compiled module will need to be defined as something 
> more closed. It
> >  may be a collection of many compiled stylesheets. What is 
> important is
> >  its property that it doesn't use/know about global objects 
> that exist
> >  outside this module (such as global variables, keys, etc). The only
> >  way to pass information to this module is by using parameters.
> > 
> > would you also ban references to functions (or non-core 
> functions) not
> > defined in the module? 
> 
> This will only be needed if the referenced non-core functions cannot
> be included/imported at the time of the compilation of the module.
> 
> > Something like that would appear to be needed if
> > you want to compile-time type-check expressions that 
> involve function
> > calls.
> 
> Yes.
> 
> It is still possible, however to manipulate nodes (template
> references) without having to know in advance the templates (and their
> signature) that will match the node at run time.
> 
> As with FXSL, the type-checking can be done at run time.
> 
> 
> > 
> > In general whatrules would you envisage for all global name 
> resolution;
> > both for references within the compiled stylesheets and for 
> references
> > in the calling stylesheet to constructs defined in the compiled
> > stylesheet?
> 
> There are different possible design decisions. The client of a
> compiled module should have a mechanism to access the type definitions
> of global objects in the compiled module. Producing these may be a
> separate option when running the XSLT processor.
> 
> The XSLT processor will check at compile time that the client of a
> compiled module communicates with the objects (functions) of the
> compiled module only using the allowed parameter types.
> 
> The reverse -- to check within the compiled module the types used by
> its client in passing template reference parameters to its functions
> -- will not be possible during compile time. Run-time type checking
> will still be possible.
> 
> 
> Cheers,
> Dimitre Novatchev
> 
> 
> 
> 
> > 
> > Wouldn't you need some analogue of import precedence for all kinds o
> > objects, templates, functions, variabes, etc?