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

[Andrew Skiba]

Atsushi Eno wrote:

>> Let's wait what MS guys will do with that bug report. It's hard to fix 
>> a bug in the interface, as it will make all managed executables 
>> incompatible with the framework. I assume that you want to be 
>> compatible with MS in the long-term, so if this bug is not going to be 
>> fixed, and .NET 2.0 has the same value for Navigator and String, then 
>> it looks that we have to follow their path.
 >
> I disagree. Actually the fact (that this enum incompatibility had not
> long been pointed out by MS users to MS) means that it scarcely
> matters on users. Then there is almost no reason to change our API
> as silly as MS.NET.

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.

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

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.

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.

Andrew Skiba.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.xsl
Type: text/xml
Size: 514 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050208/d408d001/attachment.xsl 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.xml
Type: text/xml
Size: 234 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050208/d408d001/attachment.xml