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

[Elvis]

Zitat:

Zitat von Catbytes

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

Weil es pille-palle ist, sich ein Schema für die eigenen Daten zu basteln, um sie spezifisch vaidieren zu können.
Und ja man kann auch ein eigenes Schema und das BMEcat nehmen, sozusagen ein Subset oder ein Superset eines bestehenden, xml-basierten Dokumententyps bauen.
Die binären Formate kann man getrost ignorieren, zur Not kann man sich eine Transformation (XSL) schreiben, die die XML in eines der vorgeschlagenen, proprietären Blablaformate überträgt.

[Bernhard Geyer]

Das dumme an solchen Standards ist das es für jede Sache immer mindestens 2 gibt.
Deshalb möchte ich auch noch IDOC ins rennen schmeißen.

[Catbytes]

Zitat:

Zitat von Elvis

Und ja man kann auch ein eigenes Schema und das BMEcat nehmen, sozusagen ein Subset oder ein Superset eines bestehenden, xml-basierten Dokumententyps bauen.

Stimmt. Das kann man. Muss man aber nicht. Per USER_DEFINED_EXTENSIONS in BMEcat kann man so ziemlich alles unterbringen und ist noch im Standard.

Allerdings: Einen Nachteil will ich an den ganzen Normen nicht verschweigen. Nahezu jeder Lieferant/Kunde hat so seine eigenen Vorstellungen, was "genormt" bedeuted. Da wird aus einem Kann-Feld ganz schnell ein Muss-Feld und/oder umgekehrt.

Hier in der Firma habe ich bestimmt 20 solcher "Standards" auf der Platte liegen...

Wenn es um Onlineanbidung in Verbindung mit SAP geht, schmeisse ich mal noch den EBP* in die Runde (SAP -> EBP -> Shop -> EBP -> SAP).

*EBP = Enterprise Buyer Professional ist eine E-Procurement-Komponente zum Strategic Sourcing innerhalb von mySAP SRM: Er stößt beispielsweise Freigaben, Bestellungen, Waren- und Rechnungseingänge an

[Alexander]

Zitat:

Zitat von mschaefer

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.

Die Probleme mit den Umlauten etc. halten sich auch in Grenzen. Beim De-/Serialisieren unter .NET wird das z.B. automatisch umgewandelt. Unter VCL wird es vermutlich ähnliches geben.
Und sonst gibt es noch CDATA-Abschnitte.

[mschaefer]

Ja gerade die Wandlung der VCL hat mich zu der Base64-Codierung gebracht!
Damit sind auch sämtliche anderen Sonderzeichen erledigt.

PS: Die Codierung kann ich wahlweise zuschalten, aber die Erfahrung zeigt halt, eingeschaltet gibt es keine Probleme damit.

Grüße // Martin

[Bernhard Geyer]

Zitat:

Zitat von mschaefer

Ja gerade die Wandlung der VCL hat mich zu der Base64-Codierung gebracht!
Damit sind auch sämtliche anderen Sonderzeichen erledigt.

Vermutlich hat dies mit autoamtischen Wandlungen String/Widestring bei vielen Komponeten zu tun. Bei guter und sauberer Programmierung der XML-Komponenten und entsprechender Kapslung gibt es damit keine Probleme!

[yankee]

tsss... Da denkt man mitsamt xml kommt Unicode und stattdessen nehmen die Leuts einfach base64_encode...
Warum nehmt ihr dann nicht gleich binäre Dateien? Ihr schmeisst doch einen Teil des xml-Vorteils über board!

[shmia]

Vielen Dank für die Antworten; ich fasse meine Argumente hier mal zusammen:

Zitat:

1.) hierarchische Beziehungen können in beliebiger Tiefe abgebildet werden
2.) Daten werden strukturiert gespeichert. Es ist sofort klar, welche Daten zusammengehören.
3.) Daten können im UNICODE Zeichensatz übermittelt werden
4.) Das Format ist weitgehend selbstbeschreibend. Änderungen/Erweiterungen werden von allen beteiligten Stellen sofort verstanden, ohne dass dies über eine zusäzliche Dokumentation erklärt werden müsste.
5.) XML ist ein "offener Standard" des W3C (World Wide Web Consortium). Daher ist meist schon ein reiches Instrumentarium zur Verarbeitung vorhanden
6.) XML kann über XSLT in andere Formate (z.B. HTML, PDF, CSV, ...) transformiert werden
7.) Zukunftssicher. Alle grossen Softwareunternehmen setzen auf XML
8.) XML kann über Cascading Style Sheets oder XSL in gut lesbarer Form in einem Webbrowser dargestellt werden.

Zum Thema Codierung: ich werde einfach die MSXML ActiveX Library verwenden.
Somit brauche ich mir mit Parsen und Codieren nicht die "Finger schmutzig machen".

[Bernhard Geyer]

zu 4: Schon mal probiert eine XML zu verstehen ohne Doku's zu haben. Mit richtiger Dokumentation ist es einfacher.
Erweiterungen werden nicht sofort von allen Stellen verstanden, jedoch verursachen solche Erweiterung (neue Attribute/Keys) keine größeren probleme wenn diese keine zwingend nötigen Elemente sind und die XML-Einleseroutine der Anwendungen nicht fehlerhaft sind (Also die Regeln von guten Parsern/Leseroutinen einhält).

zu 5: XML ansich ist Standardisiert. Jedoch wird man bei manchen Realisierungen (BMECat oder ähnlichen) kostenpflichtiges Mitglied in dem entsprechenden Standardisierungskremium sein und nötige Dokumentation oder Hilfe zu bekommen.

[Elvis]

Zitat:

Zitat von shmia

Vielen Dank für die Antworten; ich fasse meine Argumente hier mal zusammen:

Das wichtigste hast du vergessen: "Einfache Validierbarkeit"

[generic]

als gegenargumente:
parsen dauert länger als das parsen der csv dateien
die xml dateien werden riesig, weil xml geschwätzig ist.

als plus:
es lässt sich über dem dom baum strukturiert drauf zugreifen
es muss keinen eigene import routine entwickelt werden, da es genügend parser gibt.
xml kann signiert werden

bzw. json sein auch ganz nett zu sein. hatte neulich mal erste experimente damit gemacht.

[grenzgaenger]

also

Zitat:

shmia

sein seiner stelle würd ich erst mal fragen, was bringt mir das? deine antworten sind zwar alle schön und gut, aber die sind sehr technisch und bringen der firma gar nix. da hat ja selbst das csv noch mehr vorteile, da man fehler schnell mit jeden editor beheben kann.

aber XML hat auch 1, 2 betriebswirtschaftliche vorteile, welche nicht nur geld vernichten, so wie in deinen beispielen (wo du ja vor 'n geschäftsführer argumentieren möchtest).

• XML ist plattformunabhängig. da der zeichensatz direct codiert ist. so kann die hardware ausgetauscht werden und das ganze funzt noch immer
• bei der archivierung, braucht nicht mehr der gesamte programmcode mit archiviert werden, da durch das descriptive format, die entsprechenden informationen über den aufbau der datei direkt enthalten sind.

sonst fällt mir eigentlich auch nix ein, was XML bringen sollte... aber vielleicht kennt ja 'n anderer noch einen vorteil. was bisher gennant wurde, ist IMHO schlicht irrelevant für die fragestellung. sorry, leut...

[Ghostwalker]

Ein paar Vorteile:

- Unabhängig von Hardware und Betriebsystem

Ob du als BS nun Linux, Windows, Unix oder MacOS benutzt...die daten kannst du
problemslos verarbeiten.

- Du kannst auf eine unmenge von Tools (zum Teil Freeware/OS) zurückgreifen.

- Problemlose Übernahme in DB-Systeme. Die gängisten DB-Admin-Tools können
XML-Dateien importieren (incl. Erstellung der DB).

- Zeitersparnis bei der Programmierung (und damit Kostenersparnis) bei
Verwendung fertiger Komponenten/Tools

- Flexibilität

Am Besten an einem Beispiel:

Nehmen wir mal an wir haben 3 Programme (pa, pb, pc) die auf die Daten zugreifen.

-> Änderung bei Programm pb, brauch ein neues Feld.

Bei XML änderst du Programm pb um das zusätzliche Feld zu verarbeiten, pa und pc brauchen
nicht geändert zu werden, das sie das Feld nicht "kennen" (werden einfach überlesen).

Bei CVS-Daten mußt du i. d. R. alle 3 Programme anpassen und sei es auch nur, das das
parsing richtig funktioniert.

Ergo auch hier Zeit/Kostenersparnis.