Argumente für XML gesucht

[shmia]

Ich soll mit einem Softwareunternehmen Auftragsdaten und Artikeldaten austauschen.
Ich habe nun das XML-Format zum Datenaustausch (mit 4 Hierarchieebenen) vorgeschlagen.

Der Mitarbeiter steht dem XML-Format sehr skeptisch gegenüber und stört sich vorallem an den Tagnamen.
Er behauptet: "sobald man nur einen Buchstaben falschschreibt, funktioniert der Datenaustausch nicht mehr"
Er möchte stattdessen viel lieber ein CVS-Format mit Satzkennungen verwenden.

Also ungefähr so:

Code:

A,4711,...,...
P,....
B, Schraube,....
B, Dichtung,....

A bedeutet Auftragsdaten, P=Positionsdaten und B=Artikeldaten

Wie kann ich den Mitarbeiter davon überzeugen, dass XML die richtige Technik ist ?
PS: er ist Mitglied der Geschäftsführung

[Namenloser]

Hmm, vielleicht damit, dass man im nachhinein besser neue argumente hinzufügen kann, wenn man das programm erweitern will, und dass es von vielen programmen direkt unterstützt wird?
Außerdem hab ich gehört, dass man xml-dateien mit stylesheets verbinden kann, sodass man z.b. ohne zusätzliche software die xml-daten in einer schönen tabelle formatieren kann, die man dann im browser betrachten kann.

[Bernhard Geyer]

Zitat:

Er behauptet: "sobald man nur einen Buchstaben falschschreibt, funktioniert der Datenaustausch nicht mehr"

Stimmt ja auch. Aber wird er/der Kunde diese XML-Dateien per Hand erzeugen? Falls er es einmal richig implementiert hat (mit korrekten Tag-Namen) dürfte es keine Probleme damit geben.

Zitat:

Er möchte stattdessen viel lieber ein CVS-Format mit Satzkennungen verwenden.

Ist ne möglichkeit. Aber dann soll er auch nicht vergessen das der Elementtrenner ja auch wieder in einem Datensatz als Realdaten vorkommen kann. Wenn er dann "" als zusatzmarkierung vorschlägt dann darf er nicht vergessen das " auch in einem Datensatz vorkommen kann. Und wenn er dann ....

[hoika]

Hallo,

neben den anderen Sachen.
Wenn ich in der CSV die "Tag" falsch schreibe,
klappt der Export/Import auch nicht.

Ich würde "zukunftsweisend" mit als Argument aufnehmen.


Heiko

[hsg]

und ergänzend dazu: fehlt ein Feldtrenner, dann können gar merkwürdig Sachen passieren.

XML glänzt dagegen mit der leichteren Lesbarkeit im Browser: man sieht schnell, welche Daten wohin gehören, kann nachträglich noch Felder hinzufügen und trotzdem noch alte Dateien wieder einlesen (ist also fehlertoleranter).

[Elvis]

XML ist ein mächtiger Standard, der dir abartig viele Vorteile verschafft, ich kratze jetzt also nur ein bissel an der Oberfläche.

Du kannst XML Daten sehr einfach komplexen Validierungen unterziehen bevor du die Daten importierst.
Es gibt da hauptsächlich 2 Möglichkeiten: DTDs und XSDs.
Ich selbst bin ein großer Fan von XSDs, hauptsächlich wei sie selbst ebenfalls einfache XML Dateien sind.
Ein solches Schema beschreibt deine Daten, enthält wo Attribute erlaubt sind und wo Elemente.
Oder auch welche Wertetypen ein Attribut/Element haben darf, sogar reguläre Ausdrücke sind möglich.

Wenn ich mal grob schätzen müsste, würde ich sagen dass sich 98% aller Fehler durch eine XSD-basierte Validierung aufspüren lassen, bevor du mögliche ouchy Banana Daten auch nur anfassen musst.

Außerdem gibt es 50 Gazilion Tools für XML, und 150 Zilionen Möglichkeiten von deinem Programm darauf zuzugreifen.
Eine XML Datei ist, im Gegensatz zu einem beschissen [XYZ]SV- oder fixed size-Datei, also:

• validierbar
• gibt hinten das raus was du vorne reingeworfen hast
• ist hierarchisch
• lässt sich mit einem .xls im Browser hübsch darstellen
  (Ich habe sogar einmal irgendwo ein .xsl gesehen, was Filterung/Sortierung über Javascript erlaubte, ich Trottel finde es nur nicht mehr :cry: )
• aus dem Schema lässt sich Zugriffscode generieren, wodurch du mit dem Handling der XML-API nur wenig bis gar nix zu tun hast.[1]
  (für so ziemlich jede heutige Sprache, von Delphi, über .Net bis zu Java oder Ada)

Kurzfassung: Wer heutzutage noch solche unvalidierbaren Krüppelformate wie Inis, oder [XYZ]SV- Dateien benutzt, lebt entweder seit ein paar Jahren hinter'm Mond oder ist einfach ein Masochist.
Alleine der Einwand deiner zukünftigen Partner lässt mich darauf schließen, dass du es da mit verschollen Appollo11-Mitgliedern zu tun hast... ;)
[1]In Delphi gibt es dafür den XML Databinding Wizard.
Für .Net/Java gibt es Code Generatoren, die Datenklassen generieren, und Serialisierung übernimmt dort die Transformation zwischen Objekten und Code.

[Bernhard Geyer]

Zitat:

Zitat von hoika

Ich würde "zukunftsweisend" mit als Argument aufnehmen.

Stimmt. Dein "Gegner" ist ja aus der Geschäftsführung.
Dann sollten wir noch ein paar Schlagwörter auspacken wie "99% der Top100-Firmen verwenden XML für Datenaustausch", XML ist die Sprache im E-Commerce, ...

Ich denke wenn wir zu sehr in die technische Ebene gehen schaltet er u.U. einfach nur ab.

[mschaefer]

Also wenn es sich nur um eine Tabelle per Datei handelt ist da kein Vorteil von XML zu CSV. In dem Fall kann man die CSV-Datei bequem per Texteditor kontrollieren und das sieht sogar übersichtlicher aus als XML. Das änder sich aber, wenn man mehrere Tabellen und weitere Daten in einem File übertragen möchte.

XML-Code:

<?xml version="1.0"?>
<LIBRARY>
    <Adresse>
         <Field_1> Name 1   </Field_1>
         <Field_2> Ort  2   </Field_2>
    </Adresse>
    <Auftrag>
         <Field_1>  Auftragsdatum  </Field_1>
         <Field_2>  Lieferdatum    </Field_2>
    </Auftrag>
</LIBRARY>

PS: Einen haken hat XML-aber noch. Es reagiert etwas empfindlich auf Sonderzeichen (Umlaute, Symbole, Eurozeichen),
deshalb verwenden wir oft eine Base64 kodierung für die Nutzdaten. Damit ist das natürlich mit Notepad nichts mehr zum kontrollieren.


Grüße // Martin

[Luckie]

Zitat:

Zitat von Elvis

(Ich habe sogar einmal irgendwo ein .xsl gesehen, was Filterung/Sortierung über Javascript erlaubte, ich Trottel finde es nur nicht mehr :cry: )

Nicht weinen kleiner Elvis. Luckie ist ja da und hat den Link für dich gefunden: http://www.delphipraxis.net/internal...250&highlight= :mrgreen:

[Catbytes]

Zitat:

Zitat von shmia

Ich soll mit einem Softwareunternehmen Auftragsdaten und Artikeldaten austauschen.
Ich habe nun das XML-Format zum Datenaustausch (mit 4 Hierarchieebenen) vorgeschlagen.

Warum?

Nimm was standardisiertes. Das wird auch Deinen Chef überzeugen, wenn er sieht, wer da alles hintendran steht.

Für Artikel: BMEcat (bzw. www.bmecat.de)
Für Auftragsdaten: EDIfact oder OpenTrans
Für die Klassifizierung: eClass oder etim

Das Zeugs ist fast alles ISO genormt, bzw. es stehen die führenden großen Konzerne von Deutschland hintendran (Heiler, Oracle, IBM, SAP etc.).