Re: [xsl] Comparing node for identity using union

[António Mota <amsmota@xxxxxxxxx>]

Does the fact that i'm setting this parameter from Javascript/Sarissa
change your remark? I'm testing it now but it's too much confusing and
i don't have the time to figure it out.

But it seems there are different beahviours in the way i pass the parameter. 

Firstly i had
        pos = 1 //or whatever
	Sarissa.setXslParameter(xslDoc, "pos", pos+""); 
	xml.transformNodeToObject(xslDoc, xmlResult); 

because with 
	Sarissa.setXslParameter(xslDoc, "pos", pos); 

was giving a error (now does not give a error but gets thw wrong result)

So when i change the code to use ths XSLTProcessor i used the same

	processor.setParameter(null, "pos", pos+"");  
	var xmlResult = processor.transformToDocument(xmlDoc);  

that gives the wrong behaviour. But if i use 
	processor.setParameter(null, "pos", pos);

it works OK. So they have the opposite functioning.

When i use oXygen i get many problems when setting the params, so i
simply change the declaration
    <xsl:param name="pos" select="1"/>   or wathever number i want,
and worked ok every time with the diferent processors.

So i'm so confused now that i just want to ask a simple question.

When i set a parameter defined like <xsl:param name="pos" select="0"/>
outside the XSLT does the parameter stays a number, changes to char,
it depends on the processor, or what?


On Wed, 19 Jan 2005 14:00:49 -0000, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> > The $pos is defined like
> >
> >       <xsl:param name="pos" select="0"/>
> 
> That's certainly a number, and since positions start at 1, xyz[$pos] should
> always be an empty sequence (node-set). If, as you say, one processor is
> behaving differently from all the others, then that's prima facie evidence
> of a bug.
> 
> Michael Kay
> http://www.saxonica.com/