& XSLT >  Even in these non-XSLT contexts, I see a useful and sensible 
>  proliferation of EXSLT 
>  > extension functions, although clearly not the extension 
>  elements.  To 
>  > what degree is EXSLT really EXPath in spirit, and where do 
>  we draw the line on how powerful we allow XPath to become through
extensions?

I don't see the need to draw any line. There can be an extension function
library as big as the Java class library as far as I'm concerned: so long as
there are conformance rules that make it clear not every function will be
available in every environment.

>  > Should we identify which, if any, extension functions are only 
>  > intended for use when the host language is XSLT?  Do we want to say 
>  > anything about when the host language is not XSLT?

I think there are already too many XSLT-only functions. The main
justification for functions being XSLT-only is that (like key(),
format-number(), current-group() etc) they depend on static or dynamic
context information that comes from the XSLT processor. But there are too
many of these context-sensitive functions, and things like format-number
should be designed so the context dependency can be satisfied in different
ways by different host languages (or to avoid the context dependency
entirely).

The other mistake was putting the XSLT-only functions in the same namespace
as the core functions. This has encouraged others to follow the bad example,
in particular XForms did the same and is now in a bit of a mess because one
of its functions, if(), uses a name that's become reserved in XPath 2.0.

Michael Kay
Saxonica

_______________________________________________
exslt mailing list
list@[...].org
http://www.exslt.org/list