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

[Andrew Skiba]

Atsushi Eno wrote:
>> 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.
Of course if we were at stage of designing framework, I would agree with 
you from the beginning. But we are in situation where MS for some reason 
(let's call it design bug) made those values same. It's very expensive 
to fix this bug, as it will give you regressions like that temperature 
sample, so MS will never do that. To stay incompatible with them in 
long-term is strategically wrong. After all what we are doing here is 
implementing THEIR framework, not defining what we like. If they will 
listen to you and fix that in NET 2.0 i will be happy. But we have at 
least a year with 1.1, so I think we should change Navigator to 1.

>> 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.
Correct me if I'm wrong, for XSLT author the next two fragments look the 
same:

<xsl:variable name="foo" select=".//temperature[1]"/>

and

<xsl:variable name="foo">
	<xsl:copy-of select=".//temperature[1]"/>
</xsl:variable>

But the first one is Navigator and the second is String. May be this was 
reason to unite them. I don't like such design solution, again, but it's 
what we have.

> 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.
Sorry for confusion, here I talked about navigator.patch It will change 
the result, try it ;-)

> What if users wrote custom functions that expects RTF and string
> strictly different things? Won't they be caught in hard-to-find bugs?
In this case thay can use "is" operator to see if expression is 
XPathNavigator, that's what I did on lines 54 and 57 of navigator.patch

>> 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.
I'm talking about navigator.patch, again.

> 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."
I'm agree. Let you accept navigator.patch and blame me if anybody complains.

Thank you.
Andrew Skiba.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: navigator.patch
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050209/4fc509af/attachment.pl