Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math

Subject: Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Mon, 12 Mar 2001 10:39:50 +0000
Hi Uche,

> Maybe there should be a dyn:foo set of functions involving dynamic
> programming. dyn:evaluate would be an obvious anchor; another idea
> could be a function (dyn:vars?) that returns all names of variables
> currently in scope in node set form. And so on through the usual set
> of metaprogramming tricks.
> Some would choose not to implement the dyn module because of
> performance worries: fair enough.

I think that sounds like a really good idea. Can you come up with a
list of the 'usual set of metaprogramming tricks' that it should
include? If you give a basic list, I'll try to work them up into
another document.

> Also, should there be a function that checks whether an entire
> module is available, rather than having to check
> function-by-function? Perhaps common:module-available(string) where
> string is "math", "sets", "functions", etc.

I'd like to use system-property() for this.  What about:

  system-property('exsl:common-available') => true()/false()
  system-property('exsl:math-available')   => true()/false()

and of course:

  system-property('exsl:version')          => 1.0
Of course that's if we go with distinct modules and implementers
implementing all of a particular module.  So far I've seen David
against and you for that.

A middle path might be to have certain functions belong to a core in
each set that must be implemented for support to be claimed (so all
the ones currently specified would have to be implemented). And then
have others added to a growing repository that may or may not be
implemented. These could be moved to the core, after appropriate
discussion, when the EXSLT version goes up.



Jeni Tennison

 XSL-List info and archive:

Current Thread