RE: [xsl] converting xsl-wd to xsl1, msxml script changes

Subject: RE: [xsl] converting xsl-wd to xsl1, msxml script changes
From: "bryan" <bry@xxxxxxxxxx>
Date: Fri, 14 Feb 2003 10:01:50 +0100
>ahh. maybe this is my problem. in msxml3 (or 4) do I have to load the 
>additional msxml parser to get the values out?

you need to if you want to get a dom that you can handle as a nodeset.
If for example you had 

var xmlnodes;
xmlnodes = "<test>is a test</test>";
return xmlnodes

what you would end up with on the other end is 
&lt;test&gt;is a test&lt;/test&gt; which you should be able to get ahold
of using your xsl:value-of

>I was thinking more along the lines of, a description of what one wants
>to do with examples etc. and it could be that various people on this
>list would say - "do this instead"


<xsl:template match="/level2">
    <xsl:value-of select="msxsl:test(.)"/>

<msxml:script name="JScript" implements-prefix="test">
function test(node)
   if(node.length > 0 && node.type != "object")

I'm supposing it would be better to have

<xsl:template match="level2">
<xsl:if test="* or text()">
<xsl:value-of select="test:test(.)"/>

<msxml:script name="JScript" implements-prefix="test">
function test{node}
test="my string";

return test;

my earlier example was probably not a good one, in that it caused you to
assume what you should have was <xsl:value-of select="msxml:test(.)"/>
when what you should have is test:test(.) - test being the namespace
prefix and also the name of the function in this case, this is why
msxml:script says implements-prefix="test".
And of course one needs to return some value at the end of the function

>>Again it is difficult to give suggestions without examples, if there
>>something in these files that is proprietary than make an abstract
>>and example that requires the same handling.

>that is obviously abstract as the real thing is not mine to write out!
>Its just a passing problem of nodes. Some of those nodes have to exit 
>the program by way of a javascript function and all I get is a 0 or 1 
>length 'object' that I can't do anything with - if I do node.nodeType 
>I get 'undefined'.

See one thing is it's rather unclear what you want the whole thing to
do, you say you want to start a javascript process up but the reason? If
the reason was given we might indeed find that it was something that did
not require you starting javascript, on the other hand it might be that
it does require some process external to xslt, and we could say, well
what you need to do is the following in the application which calls the
xslt. That is to say give some design guidance.

It is at any rate not considered a good thing to have scripted
extensions inside of ones xslt as it interferes with cross-processor
portability and also could make life difficult for future maintainers of
your application. Consider if for example someone like myself had to
work with this application at some point, I would probably want to
rewrite the whole thing from the bottom up to remove the necessity of
dealing with jscript inside of my xslt. Or if the company hires somebody
who has learned xslt working mainly with xalan or saxon or the like, if
all processing is actually done inside of a scripted extension their
experience is rendered useless. Many of these issues came up in the
debate over xslt 1.1 which was never completed as a rec, a good synopsis
of the problems caused by scripted extensions can be found at 

 XSL-List info and archive:

Current Thread