nicht angemeldet
Hallo Andreas,
"Gut lesbar" ist wie ich finde irrelevant.
Im Prinzip ist das richtig.
Aber XML läßt sich eben leicht weitertransformieren in eine druckbare Rechnung z.B., die Werkzeugvielfalt und das Programmierer-Know-How nimmt zu. Ganz im Ggs. zu EDIFACT. XML lernt man schnell, eine komplexe DTD schon schwerer. Aber bei EDIFACT tut man sich schon schwer überhaupt das Grundprinzip zu begreifen: Transaktionen, Segmente usw.
Es soll sich ja im Live-Betrieb keiner die Datenpakete angucken, das ist nur eine Vereinfachung für den Programmierer. Voen wegen Flexibilität, das ist zwar wahr das XML flexibler ist, aber mit der EInschränkung durch eine vorgegebene DTD ist es auch nicht mehr flexibler als EDIFACT, oder?
Kommt drauf an, wie flexibel die DTD ist. Jedenfalls ist XML leichter änderbar (wenn es zu Änderungen kommt) als ein EDIFACT-Format. Aber Haupthemmnisse bei Änderungen können die Standardisierungsgremien sein...
Da hatet ich mich falsch ausgedrückt, ichmeien jetzt nicht direkt den eigentlichen XML-Parser, ich meine die Software die die XML-Daten z.B.in eine Datenbank schreibt. Die kann jeweils nur mit einer DTD verwendet werden, wenn eine andere DTD verwendet wird, muß man das durchaus umprogrammieren, oder?
Wenn ich in einer XML-Datei z.B. ursprünglich
<artikel>
<preis>232</preis>
</artikel>verwende, und das ganze auf
<artikel>
<nettopreis>204</nettopreis>
<bruttopreis>232</bruttopreis>
</artikel>umstellen möchte(bitte den Sinn nicht hinterfragen, ist ein blödes Beispiel)
dann kann man das zwar in der DTD global ändern, was aber nichts daran ändert, dass die Software jetzt nicht mehr auf <preis> sondern auf <nettopreis> und <bruttopreis> reagieren muß. Das hatte ich gemeint.
Wenn du das so hart rein kodierst oder die Struktur komplett änderst hast du recht. In der Regel wirst du aber deine SW so designen, dass über Konfiguartionsmechanismen Deine SW auf sowas reagieren kann oder du nutzt Tools, die dich bei sowas in generischer Weise unterstützen. Fast alle DB-Hersteller bieten da Mapping-Tools von einer XML-Struktur auf eine realtionale DB-Struktur.
Was mir gedanklich hier fehlt ist der eigentliche Standard in Form einer Art DTD, den die Firmen doch bräuchten um mit der "Beschreibungssprache" EDIFACT wirklich untereinander kompatible Daten auszutauschen.
EDIFACT ist nicht nur eine Syntax, sondern definiert ganz konkret Geschäftstransaktionen mit den notwendigen Messages. Eine Bestellung zum Bsp. kann aus verschiedenen definierten Messages bestehen und das ist standardisiert. Das ist wesentlich mehr als nur XML-Syntax. Da ist XML noch lange nicht, auch nicht ebXML oder vergleichbare Projekte. Schau dir den Hype um Web Services an. Da ist die Rede vom Aufruf von Methoden auf entfernten Servern über Firewalls hinweg (als wäre das bisher an den Administratoren gescheitert!). Hauptbeispiel: Börsenkursabfrage. Aber für langlaufende Transaktionen wie Bestellunge usw., Sicherheitsbelange u.a. gibts noch viel zu tun, bevor das wirklich in Unternehmen eingesetzt wird.
Das denke ich mir! Wenn jetzt 10% der Firmen Standard X, 20% Standard Y und wieder 17 % Standard Z, der Rest nur EDIFACT oder gar nichts, wie soll man dann Anwendungen schreiben können? Woran soll man sich halten? Wenn man mit allen Standards kompatibel sein will, braucht man eine eigene Schnittstelle zu jedem der einzelnen Standards, oder?
Ja, zumindest benötigst Du eine Art von Integration. Ob die nun Point-zu-Point ist oder auf Maping basiert oder was auch immer. Was meinst du warum die meisten Probleme in größeren Unternemen Integrationsprobleme sind. Irgendwie geht es doch immer um Schnittstellen in der IT. Außer sowas hat Erfolg und setzt sich auf der ganzen Welt durch (woran ich nicht glaube ;-): http://www.oasis-open.org/committees/ubl/.
Gruß
Franz