This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: xslt/xpath 2.0 comments ( long )


Quoting Michael Kay <michael.h.kay@ntlworld.com>:

[...]

> > ------------------------------------------------
> > 7.3.1 Defining a Stylesheet Function
> >
> > 'Issue (user-functions-vs-vendor-functions): Should
> > user-defined functions
> > override vendor-defined functions of the same name, as
> > specified here, or
> > should it be the other way around?'
> >
> >  the vendor, at the very least, should implement their function with
> a
> > namespace attatched, why would there be any overloading of
> > functions, which
> > could also be yet another bad thing with respect to security.
> >
> > If a user wanted to override saxon:evaluate() with their own
> > function named
> > saxon:evaluate(), i think an error should be thrown.
> 
> That would imply that if the user writes an emulation of saxon:evaluate
> in
> order to allow a stylesheet written for Saxon to run under (say)
> Sablotron,
> then the stylesheet containing this emulation will fail when it's run
> under
> Saxon.
> 
> The alternatives: choosing the vendor's version of saxon:evaluate() in
> preference to the user's version means that the stylesheet may produce
> different results when run under different processors. In theory, a
> vendor
> could return anything he liked in response to any extension function
> call by
> arguing that he was calling his own implementation (sounds perverse,
> but
> these things happen when it comes to running benchmarks and conformance
> tests). Choosing the user's version in preference means that instead of
> emulating saxon:evaluate(), the user would have to write a wrapper
> function
> that makes the decision whether to call user code or to call the
> vendor's
> version. This to me seems the cleanest solution.

I might be misunderstanding you, but it seems to me that given that 
the user is writing a wrapper function, they should be putting that 
wrapper function in their own namespace rather than the one for 
Saxon extensions.  So this is consistent with or supports the idea
of the processor giving an error when one of its extension functions 
are redefined.

[...]

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]