[Mono-dev] [PATCH] Validation for <xsl:output> attributes.

[Gert Driesen]

> -----Original Message-----
> From: Atsushi Eno [mailto:atsushi at ximian.com] 
> Sent: zaterdag 24 december 2005 11:16
> To: Gert Driesen
> Cc: mono-devel-list at ximian.com
> Subject: Re: [Mono-dev] [PATCH] Validation for <xsl:output> 
> attributes.
> 
> Gert Driesen wrote:
> > I submitted my initial patch the the mono-dev list, and you 
> definitely
> > reviewed this part.
> 
> It is incorrect. It was the first reply I precisely pointed out that
> HTML output is broken here, and after my reply you committed what
> you haven't posted.
> 
> > Our behaviour now matches that of MSFT, is that bad ? We 
> now have unit tests
> > that validate our behaviour and that of MSFT (as these unit 
> tests now pass
> > on both implementations).
>  >
> > You're saying that the MSFT implementation is not forward 
> compatible, so I'd
> > suggest filing a bug report with them. If they ever change the
> > implementation, you'll immediately know as the unit tests will start
> > failing.
> 
> The standalone tests deny what you say. Note that our standalone tests
> are using whatever MS.NET outputs. Thus, there is something your code
> does not match with MS.NET, or MS.NET has changed their 
> implementation.
> 
> (BTW I never said that MS implementation is not forward compatible.)

I guess MS does perform the same level of validation if the version is not
equal to 1.0.

Problem is that I cannot seem to succeed in executing the standalone XSLT
test suite :(

> > If our implementation does not match that of MSFT, then you 
> can't have any
> > unit tests that allow you to discover this.
> > 
> >> Another reason that string is better than enumeration (like
> >> Yes/No/Default/Other I guess) is that it becomes a mess 
> when someone
> >> or ourself want to reuse the code to implement his or her own XSLT
> >> implementation that supports custom output.µ
> > 
> > Again, I just followed the behaviour of the MS 
> implementation here, and got
> > your approval for the validation changes.
> 
> What I asked is to fix the problem and commit. You might have thought
> you *fixed* it, but it is not right. Thus am asking you to revert it.
> I don't see any reason that you should stick to the broken changes.

I'll see if I can find time to look into the broken changes. With broken I
mean broken compared to the MSFT implementation. 

Is that ok for you ? If not, it might be best to revert all validation
changes.

> > I really must be missing something here. If you don't want 
> me to work on
> > this, you could've said so from the start ...
> 
> There is no reason you should feel you are rejected. I just keep
> pointing out that your fix is not right.

Ok. Point taken.

> (I, of course, don't like the altitude that compatibility is God and
> it can throw better behavior away. I'm not here to reinvent MS bugs.)

I agree with you. We should not implement MS bugs, but we should stick to
their implementation as close as possible (as this will allow tests to pass
on both implementations, therefore allowing us to catch regressions/changes
in both implementations).

Gert