OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tamie message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]