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

Jochen Wezel jwezel@compumaster.de
Sat, 10 Jul 2004 11:46:01 +0200


Hi Atsushi, Ian and all the other strategy guys!

>> I could imagine that - if those bugs get reported to MS - Microsoft=20
>> will fix some of them in a next version of the .NET framework. Till=20
>> then, our highest priority should be to be 100% compatible to the MS=20
>> .NET framework behaviour and not to any other standards.
>
>
> Well, I have to disagree in some points:
>
> [...]
To be compatible to MS doesn't says that we cannot get better, please =
make a small difference here.

Our first goal should be that all those applications developed for the =
MS .NET platform should run from start without any problems.

Second, we are allowed to get better than MS by several points of view:

- 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). Here we can fix =
some behaviour which is know to the community

- 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 %.

- 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

>     - Anyways most of .NET developers are ignorant of what
>       breaks compatibility, by using "\" in path, using MSSQL
>       specific operations etc.

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!!

MSSQL specific operations are based on the database in the background. =
If you change your database, you will always get the problem with these =
things. When you created a stored procedure on PostreSQL, you hadn't got =
the chance to get it working on a MySQL 4 database. Oracle is using =
PL/SQL and there are some specific changes, too. =3D=3D> If you change =
the database, there is ALWAYS the need to change your code, in =
principle.

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).

Regards
Jochen

-----Urspr=FCngliche Nachricht-----
Von: Ian MacLean [mailto:ianm@ActiveState.com]=20
Gesendet: Freitag, 9. Juli 2004 15:28
An: Atsushi Eno
Cc: Jochen Wezel; mono-list
Betreff: Re: AW: [Mono-list] XmlTextReader: MS compatibility, or W3C =
conformance?

Atsushi Eno wrote:

> Hello,
>
> Thanks for your point of view.
>
>> I could imagine that - if those bugs get reported to MS - Microsoft=20
>> will fix some of them in a next version of the .NET framework. Till=20
>> then, our highest priority should be to be 100% compatible to the MS=20
>> .NET framework behaviour and not to any other standards.
>
>
> Well, I have to disagree in some points:
>
>     - With that "if", we cannot provide better solution than
>       Microsoft *at any time*. Also, to conform to that "if",
>       we have to make libraries vulnerable as well as Microsoft.
>
>       (That's extreme case? Yeah, but then we need certain lines.)
>
>       And if we just follow Microsoft, it won't fix any problems
>       in their libraries, since there is no better competitors.

agreed. Having more compliant libraries than ms is a great selling point =
for mono.

>
>     - Even if Microsoft fixes such problems, they will keep
>       old libraries lame, and thus "compatibility problem" will
>       remain there and in the next stage users will demand to
>       make .net 1.1 stuff as "compatible" with buggy old one.
>
> Moreover,
>
>     - We might lose some faithful developers that believes
>       standard is important (well, I have to say am apparently
>       such one of them that believes code is speech).

again - conformity to standards is important and if mono can do a better =
job than ms at this so much the better.

>
>     - Anyways most of .NET developers are ignorant of what
>       breaks compatibility, by using "\" in path, using MSSQL
>       specific operations etc.

hmm - I'd say thats a broad generalization. And even if its true it not =
a good reason for putting more obstacles than necessary in the path of =
developers writing x-platform .net code.

>
> Well, I don't intend to reject all standard-negative opinion but
> want to draw lines between MS compatibility and standard conformance.
>
> I don't want to be a black sheep here, so many of the developers
> believe that MS compatibility should take precedence at any time,
> I'll post more complete "fix" and wait anyone apply to cvs. I'd
> be glad to fix by myself if there is any rational reason.

The "ms compatibility mode" proposal introduced in another thread could=20
make a good compromise. There would be a certain amount of overhead but=20
it would make it easier to determine which exceptions/failures are=20
compatibility related and smooth the porting process. Similar to the way =

browsers like mozilla have an "ie compatibility mode" so that they can=20
display broken non-conformant ms allowable html but still make standards =

compliance a top priority. Having our cake and eating it too - with a=20
slight cost in complexity.

Ian