[Mono-list] XmlTextReader: MS compatibility, or W3C conformance?

[Atsushi Eno]

Hello,

 > - as already suggested, we could enable a "mono power mode" as
 > Ian described (first it should be the MS compatibility mode to
 > ensure all applications from the MS.NET world are running fine).

Agreed. We can provide "MS.NET compatible mode" as one option.

 > - Standards are important, but when you only believe on the pure
 > standard, you're never allowed to use DVD+R/+RW drives or mediums ;-)
 > That's why I recommend to accept that there might be some situations
 > which should allow proper (reading) functionality even if the standard
 > is not matched to 100 %.

No. That never means that Microsoft can ignore existing standards.
Also, you (as a pure standard believer) might not be able to use
non-standardized libraries (I never think so), but standard-based 
libraries should be available as being subject to the standard.

 > - we are already better than MS because we've got a lot of
 > additional goodies in our project (or associated projects), here
 > only a few: Mono.Data with several great Providers for PostgreSQL,
 > MySQL, Oracle, DB/2; IKVM; Support of ALL IMPORTANT PLATFORMS:
 > Windows, MacOS-X AND Linux

That does not mean we can break W3C standard in the name of Microsoft
compatibility, nor does not mean that mono improvements should be
limited to non-MS-touched part. Here still no lines drawn, or I cannot
agree with your "always MS.NET rules" line.

 > Sure, there might be some developers which are only focussed to the
 > Windows world and are using "\" instead of
 > System.IO.Path.DirectoryCharSeparator. This will be the most often
 > problem and we should find a possibility to wrap those paths when
 > accessing files. If we get this working, we've won a lot!!

No, you cannot depend on our class libraries. It is impossible to
identify if a relative path string is windows path or unix path.
You cannot say that "foo\bar" is always windows path that represents
bar directory under foo directory.

 > But all the other traps from moving applications from the windows
 > world to mono and its supported platforms should be closed. Or at
 > least there should be a small tool which analyses the code for traps
 > and suggests changes (maybe in a similar way as Microsoft's migration
 > assistants or FxCop do).

Ok, that does not matter if we provide a MS.NET compatibile mode. Well,
of course it would be nice if anyone can contribute such compatibility
tool (though I have no idea how such tools work), or summarize
problematic points on porting (as partly Jackson has written on his
asp.net application portings).

Atsushi Eno