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

[Atsushi Eno]

Andrew Skiba wrote:
> Atsushi Eno wrote:
> 
>>> 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.
> 
> 
> In NET 2.0 this enum is intact, BTW.

That's why I posted to MS feedback. No worthy of saying like that.

>> 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?
> 
> 
> You see, 99% of times you want to regard RTF as string. Look at my 
> patch. I deleted code all the time, because it's easier when Navigator 
> and String are the same thing. Only once in EqualityExpr.EvaluateBoolean 
> I had to distinguish between RTF and string (lines 54 and 57 in attached 
> patch). So in those rare cases you are done easily with "is" operator. 
> In whole System.Xml there is only one place when you need to distinguish 
> between those cases, an average user will never need to do that.
> 
> I agree with you that XPathResultType.Navigator is buggy. It must have 
> been called XPathResultType.NavigatorOrString from the beginning.

I never thought such enumeration could ever exist, while XSLT spec
explicitly shows there is a result tree fragment type.

>>> 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.
> 
> No, and that's the IMPORTANT moment. MS.NET users don't have to handle 
> Navigator separetely, as it's done automagically by the String case. 

XSLT spec never automagically regards result tree fragment as string.
I think you are mixing specific code/stylesheet case and general spec
difference.

> It's the key moment in our discussion. I state, that the enumeration was 
> on purpose done like this, so you will not have a bunch of hard-to-find 
> bugs like the bug with temperatures that I shown you in the previous 
> message.

That is not my point. Note that I get that result without your patch.
(If I got the same result _with your patch applied_, what do you
think is my point?) I mean, even with XPathResultType.Navigator = 4,
the example code shown in the URL above did not show the actual
difference.

Again, that bug is nothing to do with XPathResultType. You are mixing
different discussion. We are not talking about "What people can do
if XSLT engine has a problem?" My answer is

"Am sorry but we can never be perfect. We might write buggy code."

What if users wrote custom functions that expects RTF and string
strictly different things? Won't they be caught in hard-to-find bugs?

>> 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]"/>
>>
> 
> The thing is, this bug disappears if you apply my navigator patch. And 
> you can only imagine, how many such bugs you have to find yet. 

Again, that happens without your patch, and that still happens even
with your patch. The fact looks natural to me. I can't understand
that the XPathResultType value change can affect on the stylesheet
which never uses result tree fragment.

> Actually, if you don't fix the enum, you have to grep all the code for 
> XPathResultType.String and add XPathResultType.Navigator in EVERY place. 

BTW, as I have been said over and over again, RTF is not the same as
string. RTF is rather NodeSet and it basically conforms to rules for
Nodeset. If it looks like the same as string, it's just a subsequential
type promotion result. NodeSet could be evaluated as a number, a
boolean or a string.

That's nothing because both XPathResultType.String and
XPathResultType.NodeSet are less than 30 lines and most of them
denotes just return type of each function. I have grepped those
values during this niche discussion.

> It's wrong, as you cannot change the users code, which works with .NET. 
> Moreover, even if users wanted to be compatible with both Mono and .NET, 
> they could not, because of duplicated case error. Do you think they will 
> maintain separate source code for Mono and .NET?

I think 99.9% of people have never written incorrectly
XPathResultType.String-dependent extension functions yet (and it is
buggy, anyways).

Ok, am really tiredof this niche discussion. If we continue, I'll just
change XPathResultType.Navigator to 1. It consumes my productivity
extraneously and I myself is not strict W3C believer. But when people
start to say that mono users want buggy implementation than W3C
conformant implementation, I'll just say "I did resist."

Atsushi Eno