Ist mir schon mal mit XML-Modulen von Perl passiert, war ein böser Reinfall. Kollegen von mir sind mit bestimmten beworbenen Funktionalitäten von MS-Produkten auf die Fresse gefallen. Shit happens.
Dazu wuerden mich jeweils Details sehr interessieren.
Es war nicht LibXML (oder wie das Ding genau hiess). Habe mit expat (einem nichtvalidierenden XML-Parser) und XML::Simple meine Erfahrungen gemacht, eventuell noch das eine oder andere Perl-Modul an das ich mich nicht mehr erinnern kann. LibXML soll der beste XML-Parser für Perl sein. Dennoch würde ich das Ding mal gerne richtig testen wollen, Zweifel bleiben. - Überigens wurden die Probleme irgendwann dadurch gelöst, dass alle XML-Perlmodule von CPAN rausgeschmissen wurden und der XML-Parser von MS zum Einsatz kam (in Perl ;).
Insgesamt glaub ich aber, dass ich da etwas
grundsaetzliches falsch mache. XML/XSLT/XPath et al.
sind seit Jahren derart "gehypt" das es immer
schwer zu glauben ist, wenn bei so weit verbreiteten
Technologien wie PHP und Perl derart massive Probleme
auftreten.
Ich glaube, dass Themen wie bspw. XML und UTF immer noch irgendwie Randthemen sind in der GPL-Gemeinde. Schade eigentlich. Warum das so ist? Keine Ahnung. - BTW, MySQL ist auch mit einer gewissen Vorsicht zu geniessen, wenn man "Ansprüche" (Replikationen, Transaktionen, SPs etc.) hat.
Wenn die MS - Probleme sich auf MSXML beziehen,
poste es bitte !
Nein, der XML-Parser ist verdammt gut.
Das ist eines der wenigen MS-Produkte dem ich nach
'zg Jahren ein vertraue - und das hab ich auch
Kollegen so vermittelt...
MS Exchange und MS SQL Server sind auch ganz gut. Studio find ich auch OK. (Von den Office-Produkten ganz zu schweigen, kennst Du openoffice? ;)
Gegenfrage: Wie gehen Deine Kollegen und die Leute an die Du berichtest mit sowas um?
Bei dem jetzigen Projekt bin noch alleine und muss
nicht "reporten". Zum Glueck.
So wie eine Bekanntschaft oder Freundschaft erst dann ihre Qualität beweist, wenn es mal Differenzen gibt, so bestätigt sich die Qualität eines Arbeitskollegentums auch erst im Konfliktfall. Und da das gute alte Scheitern im IT-Bereich normal ist (angeblich scheitern 50% der Projekte mehr oder weniger), ist das richtige Verhalten im Falle des Scheiterns ganz, ganz, ganz wichtig. (Insb. sind "Schuldfragen" (entgegen der allg. Meinung) durchaus zu bearbeiten, allerdings mit der grösstmöglichen Verständigkeit. :)