In addition to the import precedence problem there is an even bigger
problem with this approach. It is well described in the XSLT 2.0 spec:
"Note:
The fact that a function with a given name is available gives no
guarantee that any particular call on the function will be successful.
For example, it is not possible to determine the types of the
arguments expected."
It seems to me that it is an indication of not too-good design to
check if a function is available at run time.
If this is indeed needed, in FXSL one can provide a default
implementation for every possible function (a template matching any
element) with a default behaviour (for example such as outputting
"Not implemented yet"
).
Then one has to import this default implementation *before* any other imports.
As I said before, while this is possible it seems similar to a giraffe
who tries to drink water from a deep well.
--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
On 7/18/07, John McGowan <john(_at_)steakfest(_dot_)com> wrote:
I'm trying to optimize a code reuse without duplication situation here.
My current solution, is using saxon:evaluate() to call the potentially
unavailable function inside of a conditional that checks
function-available. I'm considering doing something different
utilizing import precedence to control what gets used when.
My only problem with that is it causes me to go in a different
direction with how my XSL is stored and executed. I'm using
middleware to generate most of the xsl, so I'm not really using import
or include that much, because I don't really have anything sitting out
on the filesystem. It seems like the only way to define duplicate
functions, will be to define them at different import levels, which
will force me to do some re-architecting.
In the long run I think it's what I want though.
/John
On 7/18/07, Michael Kay <mike(_at_)saxonica(_dot_)com> wrote:
> The assumption is that as the author of the stylesheet, you know what it
> contains.
>
> The idea behind use-when is that it allows you test factors external to the
> stylesheet itself, for example information about the XSLT processor or the
> environment in which it is operating. If the design required you to look at
> the contents of the stylesheet before deciding which parts to filter out, it
> would get very circular.
>
> Michael Kay
> http://www.saxonica.com/
>
> > -----Original Message-----
> > From: john(_at_)sevenac(_dot_)com [mailto:john(_at_)sevenac(_dot_)com] On
Behalf Of
> > John McGowan
> > Sent: 17 July 2007 21:25
> > To: XSL List
> > Subject: [xsl] function-available() test on stylesheet functions
> >
> > I was trying to use function-available() to try to determine
> > if a stylesheet function had been defined. I eventually
> > figured out that stylesheet functions are not in the proper
> > context to cause
> > function-available() to ever be true.
> >
> > So my question is, is there another way to test to see if a
> > stylesheet function exists?
> >
> > --
> > /John
> >
> > --~------------------------------------------------------------------
> > 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>
> --~--
>
>
--
/John
--~------------------------------------------------------------------
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>
--~--