[Mono-devel-list] Re: Fixes to XSLT

[Atsushi Eno]

Hi,

> The long-term compatibility with Microsoft.NET is very important. If MS 
> will change this enum after your bug report, then you are right. We can 
> wait some time before they become compatible with us. But I want to 
> know, when we decide that we waited enough, and fix Mono interface to be 
> same as MS's.

I don't think it is important. MS.NET themselves contain its internal
implementation changes even between non-SP1 and SP1 that breaks
compatibility.

Of course, there are many compatibility-breaking bugfixes in 2.0. Users
should not depend on the buggy part of framework.

Also, there is no Navigator use case that differentiates the behavior
which comes from those enum difference.

Anyways, do you really think XPathResultType.Navigator is NOT buggy?
What happens if a user implements such XSLTfunction that is intended
to return result tree fragment, not a string?

> But there are strong reasons to think that MS will not change this enum. 
> Except backward compatibility problem, that I talked before, there is a 
> usage problem. In MSDN samples you can see code like this:
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemxmlxpathxpathexpressionclassreturntypetopic.asp 

That example code does not differ between MS.NET and Mono.

> You see, there is no case for Navigator because it's handled together 
> with the String. Because from user's point of view, usualy there is no 
> difference between them. Today's version of Mono already has issues 
> because of different enum values for String and Navigator. Try the 
> attached XML and XSL with Mono processor, and it will decide that 67 > 
> 78. Needless to say .NET outputs "good" while Mono outputs "bad". It 
> happens because variable $big is not handled as String with value 78, 
> but as a navigator to temperature[3], and 
> RelationalExpr.EvaluateBoolean() does not handle this case. That's the 
> real problem, because every time you check for XPathResultType.String, 
> you must OR this check with XPathResultType.Navigator. Those checks 
> don't exist neither in Mono code, nor in users code. When you have a 
> switch/case statement it's even worse, because if you add 'case 
> Navigator' in every place you have 'case String' it will not compile 
> with existing enum because of duplicated case error.

Ok, that sounds like a bug. But it is nothing to do with
XPathResultType enumeration. It is apparent because the bug
still happens even if you select "small" value as:

	<xsl:variable name="small" select=".//temperature[2]"/>

> So I don't beleive MS will change their interface.
> 
>>> Except this, there is always a possibility that it was not bug at 
>>> all, may be they changed Navigator from 4 to 1 at some point of 
>>> development for some reason.
>>
>>
>> I agree. I have no idea right now though.
> 
> 
> You see, my assumption now looks right. The reason for having the same 
> value is obvious now.

No, as I noted above.

Atsushi Eno