Re: [tamie] minutes 1/6 uploaded, + check Actions Item list !

[Stephen Green <stephen.green@documentengineeringservices.com>]

Having looked around a bit more (but I confess I haven't yet read the
XSLT 2.0 spec) I came across this posting

http://www.biglist.com/lists/xsl-list/archives/200304/msg00407.html

which evidences the extent to which XSLT 2.0 tries to keep its functions
(as does XPath, it seems) side-effect-free. This is of course, the Haskell
principle at work. There seems to be a slight admission that producing
output might be construed as a side-effect but that is not the intention
when the function is merely returning a result which is (it seems - in
principle at least) the only output it produces: i.e. there is no use of
'xsl:result-document' in the xslt function. That is what this mailing says
but maybe things changed in XSLT 2.0 and for that I guess I'll have to
read the spec. :-)

I guess we can in any case defer the actual content of an ETSM function
to the spec of the underlying implementation to the extent that we let
the issue of how far the no-side-effects-in-functions principle is applied
(whether, say, the event board can be updated by a function). Or else
we actually specify what XSLT tries to adhere to - that functions MUST
be free of side effects *except* when using vendor-specific ETSM
processor extensions (e.g. XSLT processor when the ETSM uses XSLT
in an implementation). In either case we can probably try advise that
when functions do allow side-effects (e.g. when extended with java, etc)
there should be consideration that if ETSM is implemented in XSLT then
the sequence of actions performed by the underlying XSLT processor
may not be as expected and may be unpredictable.

Best regards

Steve



2009/1/17 Stephen Green <stephen.green@documentengineeringservices.com>:
> Regarding AI-Jan09-1   XSLT extended functions:
>
> As pointed out by XSLT 2.0 editor Michael Kay in his book XSLT 2.0
> Programmer's Reference, the specifications for XSLT 1.0 and XSLT 2.0
> deliberately did not specify whether or not a vendor should provide any
> facility in an XSLT processor for allowing XSLT stylesheet functions to
> be extended with another programming language. M. Kay points to the
> fact that comments were made in opposition to XSLT 1.1 specifying a
> way to allow extension function bindings to particular languages and
> he refers to http://xml.coverpages.org/withdraw-xslScript.html to explain
> how this came about.
>
> I would conclude that in principle we would be amiss to specify such
> extensions to functions in ETSM scripts. All, it seems, we should do
> is allow for the fact that exensions optionally provided by vendors could
> be used when defining an ETSM function but that how that should or
> could be done would depend on the XSLT tool used. In fact it might be
> that a tool would comply with ETSM and TaMIE script processing but
> not allow ETSM functions to be written which include use of languages
> such as Java, ECMAScript, C# or whatever.
>
> Scripts, classes or source code included in extended ETSM functions
> when a tool is used which supports such extensions would typically,
> as a key feature support side-effects such as writing to the event board
> as well as reading from it. This is one reason for using these non-XSLT
> languages in the first place since XSLT functions do not, as a rule (I will
> check on this) allow side-effects in functions. I need to do more reading
> in this area. We might want to make a rule (in support of the XSLT
> 'binding'? of ETSM) that disallows side-effect in functions *except* when
> tools are used which support extended functions written in langauges
> other than ETSM and XSLT. Then, if ETSM is implemented in a language
> other than XSLT it can still make a distinction between mandatory support
> for a side-effect-free function and an optional support of extensions which may
> include side-effects where appropriate.
>
> I guess I need to put something on the wiki to this effect and folk can comment
> on this or change it. First I'd like to see if it gets any agreement
> in general by
> the TC. Thanks
>
> Best regards
>
> Steve
>
>
> 2009/1/16 Durand, Jacques R. <JDurand@us.fujitsu.com>:
>> in wiki:
>>
>> http://wiki.oasis-open.org/tamie/2009-01-06Minutes
>>
>> Check the Action Item list for this coming Tuesday meeting :
>>
>> --------------------------------------
>>
>> AI-Dec08-3: Cho and KIEC to provide more input on desired event structure,
>> and use cases for using more than one Event Board.
>>
>> AI-Jan09-1: S.G.: investigate how XSLT uses functions, how it embeds Java
>> code.
>>
>> AI-Jan09-2: Cho: to add requirements and rationale for using
>> several event boards in same monitoring script.
>>
>> AI-Jan09-3: Dale/Stephen: define Use Case #3 precisely enough, to be ready
>> for scripting.
>> Add a UML diagram that will show support for PartialAcceptance.
>>
>>
>> -jacques
>
>
>
> --
> Stephen D. Green
>
> Document Engineering Services Ltd
>
>
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice