Re: [xsl] Javascript for extension functions

["bryan rasmussen" <rasmussen.bryan@xxxxxxxxx>]

excuse typos in the mail :)


On 9/10/07, bryan rasmussen <rasmussen.bryan@xxxxxxxxx> wrote:
> Well the thing about javascript is that much of its power depends as
> to what hooks it has to the system it is in. But let us suppose that
> the javascript implementation in the processor has access to the
> system external to the processor greater than the processor gives xslt
> itself.
>
> An example would be MSXSML which can take extension functions written
> in any ActiveScripting language, thus you can use ActivePerl and
> ActivePython as well as javascript and vbscript as the extension
> language.
>
> By doing this one can easily build one's own XML DSL's. As an example
> I wrote the following in a document for the oioxml project which I
> can't find the most current version but this one will do, (text quoted
> below, tested in MSXML 4 running in MSXSL, not sure about newer
> versions of processor):
>
> http://www.oio.dk/files/OIXML_XSLT_Guidebook.pdf
>
> "The use of extension functions and elements is often justified on the
> basis of speed, given that in most processors the calling of such a
> function would add some overhead before the speed benefits could be
> calculated this argument is not a good one, as noted by Dimitre
> Novatchev here in his discussion of using XSLT for specific functions
> instead of a javascript extension
> http://sources.redhat.com/ml/xsl-list/2002-09/msg00745.html and also
> in the third page of his article on his EXSLT implementation
> http://www.xml.com/pub/a/2003/08/06/exslt.html?page=3
> In some processors extension functions can be handled via a script tag
> in the processors namespace, this was also followed in the case of
> XSLT 1.1, which was never issued as a W3C recommendation due to a
> decision to go forward with XSLT 2.0 development. This possibility of
> a script tag was vigorously fought against by the XSLT community,
> including a petition not to allow an xsl:script element
> http://www.biglist.com/lists/xsl-list/archives/200103/msg00000.html .
>
> Given that all the languages we can think of off-hand that are used in
> these script tags have an eval function or similar capabilities it
> follows that a function could just be implemented to analyze arbitrary
> scripting code.
> An example of such a usage of a script extension, for informational
> purposes because of the obvious security issues involved in such a
> scenario, is shown below for msxsl
>
> <?xml version='1.0' encoding='UTF-8'?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
> xmlns:msxsl="urn:schemas-microsoft-com:xslt"
> xmlns:jsc="http://www.somefakeurl/jsc";
> xmlns:js="http://www.somefakeurl/jscriptEvalExtension";
> version="1.0"
> extension-element-prefixes="msxsl xsl js jsc"
> >
> <xsl:output method="xml" encoding="UTF-8"/>
> <msxsl:script language="JScript" implements-prefix="jsc">
> function jseval(value){
> valparam = eval(value);
> return valparam;
> }
> function jsshell(param){
> var WshShell = new ActiveXObject("WScript.Shell"); WshShell.Run(param);
> var out = param + " done";
> return out
> }
> function jsGetVar(value){
> stempval = eval(value);
> return String(stempval);
> }
>
> <![CDATA[
> function isAlien(a) { return isObject(a) && typeof a.constructor != 'function';
> }
> ]]>
> </msxsl:script>
> <xsl:template match="*"><xsl:copy><xsl:copy-of select="@*"/>
> <xsl:apply-templates/>
> </xsl:copy></xsl:template>
> <xsl:template match="js:runStraight" ><xsl:value-of
> select="jsc:jsevalErr(string(.))"/>
> </xsl:template>
> <xsl:template match="js:getJsVariable" >
> <xsl:value-of select="jsc:jsGetVar(string(@name))"/></xsl:template>
> <xsl:template match="js:variable" >
> <xsl:variable name="var"><xsl:apply-templates/></xsl:variable>
> <xsl:value-of select="jsc:eval(concat(string(@name),'=',string($var),';'))"/></xsl:template>
> <xsl:template match="js:shell" ><cmdrun><xsl:value-of
> select="jsc:jsshell(string(.))"/></cmdrun></xsl:template>
> </xsl:stylesheet>
>
> This stylesheet will copy all elements directly except for those
> elements in the js namespace, those elements in the js namespace it
> will evaluate with script in the jsc namespace, the jsc namespace is
> just javascript.
>
> ... followed by some simple explanations....
> Running the stylesheet above against the following example:
>
> <?xml version="1.0"?>
> <test xmlns:js="http://www.somefakeurl/jscriptEvalExtension";
> >
> <example>
> <desc>send the string from js:runStraight to an eval function, returns
> string</desc>
> <js:runStraight>blah ='blahs';</js:runStraight></example>
> <js:variable name="foo">'bar'</js:variable>
> <p> the next tag gets the value of foo which was set by the former tag. </p>
> <js:getJsVariable name="foo"/>
> <p> the next tag gets the value of blah </p>
> <js:getJsVariable name="blah"/>
> <p> now we change the value of blah </p>
> <js:runStraight>var blah; blah= &quot;new blah&quot;;</js:runStraight>
> </test>
>
> results in the following output:
> <?xml version="1.0" encoding="UTF-8"?><test
> xmlns:js="http://www.somefakeurl/jscriptEvalExtension";>
> <example>
> <desc>send the string from js:runStraight to an eval function, returns
> string</desc>
> blahs</example>
> bar
> <p> the next tag gets the value of foo which was set by the former tag. </p>
> bar
> <p> the next tag gets the value of blah </p>
> blahs
> <p> now we change the value of blah </p>
> new blah
> </test>
>
> Furthermore, if we make the following instance:
> <js:shell xmlns:js="http://www.somefakeurl/jscriptEvalExtension";>cmd</js:shell>
> the xml result will be the following:
> <?xml version="1.0" encoding="UTF-8"?>
> <cmdrun>cmd done</cmdrun>
>
> and when running the stylesheet from an environment that has rights to
> call the command line such as msxsl.exe cmd.exe will be called
> "
> ... followed by a screenshot of this outrageous security violation
> taking place :)
> ....
>
>
> "For various reasons, such as possible faults in the xslt processor,
> we would not recommend using this method for script storage, however
> it does provide a theoretically interesting example of how an
> extensible programming interpreter might work, following the ideas
> presented by Gregory v. Wilson
> in his article for acmqueu as such we think it provides an interesting area of
> experimentation..."
>
> Of course the example above was sort of stupid because I would never
> just eval from input, so I have to admit I couldn't think of a good
> example.
>
> As for XMLHTTP that is implemented in different ways in different
> browsers, in IE it exists as an ActiveXObject, this was the first
> implementation, as such you can use it as an extension in MSXML.
>
> However I think an extension for all HTTP verbs in SAXON would be more
> xsl-licious.
>
>
> Cheers,
> Bryan Rasmussen
>
>
> On 9/10/07, Abel Braaksma <abel.online@xxxxxxxxx> wrote:
> > Colin Paul Adams wrote:
> > >     Abel> surely it will, esp. because most PHP programmers write for the
> > >     Abel> internet and this usually requires ecmascript/javascript
> > >     Abel> skills: it is familiar already.
> > >
> > > But is it useful?
> > >
> > > What will the programer be able to do that (s)he cannot do with
> > > xsl:function?
> > >
> > > If using the host language, I can envisage various answers, but Javascript?
> > >
> >
> > One thing that I dearly miss from the XSLT spec is a way to do a POST
> > request (i.e., retrieve a SOAP or JSON XML document through web
> > services). With JavaScript one has the ability to use XmlHTTPRequest
> > which can be used for issuing a POST to the server and returning an XML
> > object.
> >
> > Another thing you can do is check the existence of an external resource,
> > i.e., if you use unparsed-text-available() the function will fully parse
> > the text and will only fail or succeed. It won't say, for instance, that
> > the UTF-8 contains invalid characters. I happen to work a lot with
> > external resources. Knowing the difference between the availability of a
> > URL and the unparsability of a URL is of great value to me.
> >
> > And I'm sure there are other things that cannot be done through
> > xsl:function. I.e., try to process a ZIP file will be rather hard
> > (meaning: impossible) in XSLT because of the &#x0; characters.
> >
> > -- Abel Braaksma