[xsl] Scope of side effects in extension functions

Subject: [xsl] Scope of side effects in extension functions
From: Colin Paul Adams <colin@xxxxxxxxxxxxxxxxxx>
Date: 04 Aug 2005 22:13:18 +0100
>>>>> "Michael" == Michael Kay <mike@xxxxxxxxxxxx> writes:

    Michael> But that's all legalese. The practical point is that the
    Michael> extension function mechanism is there to enable vendors
    Michael> to provide extensions for the benefit of people who want
    Michael> the extra functionality and are prepared to pay the price
    Michael> in portability. So whatever the small print says, it's
    Michael> entirely within the intent of the spec.

OK.
I feel that a few words of caution could usefully be added to the
note in the spec, so that

There is no prohibition on calling extension functions that have
side-effects (for example, an extension function that writes data to a
file). However, the order of execution of XSLT instructions is not
defined in this specification, so the effects of such functions are
unpredictable. 

becomes something like:

There is no prohibition on calling extension functions that have
side-effects (for example, an extension function that writes data to a
file). However, the order of execution of XSLT instructions is not
defined in this specification, so the effects of such functions are
unpredictable, and may cause behaviour that is otherwise inconsistent
with the provisions of this document.

as I would certainly have not expected this to be the case, in the
light of:

    Michael> With extension attributes, the WG has pinned down quite
    Michael> carefully what they can and can't do.

-- 
Colin Adams
Preston Lancashire

Current Thread