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

Atsushi Eno atsushi@ximian.com
Sat, 10 Jul 2004 20:06:26 +0900

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