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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] client side paging using , Subscriptions @ Team | Thread | [xsl] Count preceeding sibling but , Taco Fleur |
RE: [xsl] "xmlns" problem for trans, Michael Kay | Date | Re: [xsl] "xmlns" problem for trans, Chenzhou Cui |
Month |