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(_at_)gmail(_dot_)com]
Sent: 13 June 2005 22:00
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Re: [exslt] Re: [xsl] Importing compiled
stylesheets
On 6/13/05, David Carlisle <davidc(_at_)nag(_dot_)co(_dot_)uk> 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?
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--