Standards für Datenformate

[Michael Schröpl]

Hi Andreas,

verstehe ich jetzt nicht. was kann man bei Bestellungen und rechnungen so groß verschiedene Anforderungen haben? Die Daten sind ja sogar gesetzlich festgelegt die eien Rechnung enthalten muß,

nach den Gesetzen welcher Nation? Willkommen im Zeitalter der Globalisierung ... ;-)

Edifact mag ein Standard sein - aber soweit ich das mitbekommen habe, ein Standard auf der Abstraktionsebene von XML, nicht von HTML. Und was nützt Dir XML ohne die Definition einer DTD, an die alle Beteiligten sich halten? Aus Deiner Sicht ist diese DTD der gewünschte Standard - XML oder Edifact sind nur die Notationssprachen.
Hm? so wie ich das bis jetzt verstanden habe(http://www.edifactory.de/openhtml.php3?ref=%2Fediexam1.htm) wird doch innerhalb des edifact-dokuments einiges definiert, und der Rest ist vorgeschrieben.

Das, was diese Seite definiert, ist nicht Edifact, sondern eine Anwendung davon. Genau wie XHTML eine Anwendung von XML ist. Nimm den Link aus meinem vorherigen Posting - das ist auch eine Anwendung von Edifact, nur eben mit einer anderen "DTD". Edifact beschreibt nur, wie man die "tags" notiert - nicht, was sie bedeuten.

Außerdem weiß ich das einige Firmen das einsetzen.

Klar - wir ja auch.

Vor allem in einer Branche werden die Unterschiede nicht so groß sein.

Mit "Branche" hat das gar nichts zu tun, sondern mit "Anwendungszweck".
Zwei Sprachen sind einander bezüglich ihrer Verarbeitung nicht dann ähnlich, wenn diese Ähnlichkeit sich auf die Syntax beschränkt (weil beide beispielsweise aus "tags" bestehen) - wesentlich für die Auswertung von Informationen sind die Inhalte, nicht die Form.
Das siehst Du ja an Deinem Projekt mit dem dynamischen Datenbankformat: Schon die Syntax ist etwas, das man am liebsten einheitlich hätte, aber wenn Du die Semantik der Daten nicht mehr verstehst, wie willst Du dann diese Daten auswerten? Was nützt es Dir beispielsweise, wenn Du den Inhalt einer Datenbanktabelle als "Tabelle" anzeigen kannst, falls diese Tabellendaten für sich selbst gar keine nachvollziehbare Bedeutung haben, sondern nur im Kontext mit anderen Tabellen? Was nützt es Dir, eine Liste von Fremdschlüsseln auf eine andere Tabelle auszugeben, deren Bedeutung niemand verstehen kann, weil er diese andere Tabelle nicht hat und weil Dein Datenmodell auf syntaktischer Ebene nicht "weiß", daß diese Werte Fremdschlüssel sein sollen, die Anzeige des Tabelleninhalts ohne die entsprechenden JOINs also für eine inhaltliche Betrachtung gar keinen Sinn machen kann? (Reine Debug-Anzeigen eines Developers mal ausgenommen.)

Na gut, bevor Du mich schlägst, mache ich halt mal ein bißchen Werbung: ;-)
     http://www.isys.ch/news/vdf_d.html
(nein, das habe ich nicht gemacht - nur versucht, es zu decodieren ...)
sowas komplexes will ich ja gar nicht. Es reichen erstmal Bestellungen. Oder meinst Du das so gut wie alle großen Firmen noch  mit Fax/Brief/Telefon arbeiten?

Ich meine, daß sehr viele verschiedene Firmen mit sehr vielen unterschiedlichen Methoden arbeiten. Wenn Du einen _Standard_ setzen willst, brauchst Du entweder die Obermenge über alle diese Methoden in Deinem Datenmodell, oder die Macht, viele bzw. alle Firmen dazu zu bringen, auf eigene, liebgewordene und in deren Software bzw. Arbeitsmethodik eingebrannte Features zu verzichten, um sich Deinem Standard unterzuordnen. Für diesen Verzicht mußt Du ihnen dann massive Gegenleistungen bieten können.

Die kleinen sicherlich, aber die größeren? Es _gibt_ doch bereits einen elektronischen Verkehr an Geschäftsdaten, und es _bringt_ den Firmen ja auch einiges, udn gerade Sachen wie Rechnungen und bestellungen sind doch IMHO weitgehend standardisiert. Wenn ich mir 10 Rechnungen angucke enthalten alle so gut wie dieselben Angaben. Wo soll da ein Problem sein? Verschiedene Zahlungsmodalitäten? Wie viele gibt es denn? 10? Nichtmal. Natürlich kombiniert mit Zahlungszielen und Skonti, aber das ist bis auf die genaue Kombinbation dieser Daten doch in allen Unternehmen gleich!

Das "so gut wie" und das "bis auf" sind aber das Problem. Jemand, der Deinen Standard unterstützen will, muß diesen vollständig unterstützen - egal, welche Teilbereiche davon er bisher nur im Angebot hatte.
Wenn sich ein Betrieb an Deine Norm halten will, dann kann sie nicht einfach eine Zahlungsform ablehnen, nur weil ihre Software das nicht unterstützt. Das ist in Deinem Fall _sehr_ viel kritischer, als wenn ein Browser eine Seite falsch anzeigt, weil er den Standard nicht korrekt oder nur teilweise unterstützt.

Ob Du einen Standard für Zahlungsverkehr auf Edifact oder auf XML basieren lassen willst, das ist zunächst einmal relativ unwichtig, solange Du die semantische Seite des Problems betrachtest.
Gibt es Informationen, die Du darstellen können mußt, die aber von etablierten, auf Edifact basierenden Standards nicht abgedeckt werden? Gibt es inhaltliche Defizite in den bestehenden Standards? Gibt es einen Bedarf, den Standard durch einen neuen, mächtigeren Standard abzulösen, basierend auf dem neue Anwendungen möglich wären? Wenn Du dies mit "ja" beantworten kannst, dann baue einen neuen Standard - und lasse den dann auf XML basieren, wenn Dir danach ist (denn das kostet zwar viel mehr Speicherplatz, ist aber viel besser human readable - und Komprimierung läßt sich auf einer niedrigeren Kommunikationsebene implementieren). Denn der Anpassungsaufwand bestehender Anwendungen ist im Bereich der Semantik viel höher als im Bereich der Syntax ... der Parser, welcher Edifact nach "Semantik" übersetzt, ist relativ einfach durch einen XML-Parser abzulösen, aber einer Anwendung beizubringen, ihre internen Datenmodelle an neue Anforderungen anzupassen, das kann sehr viel schlimmer sein.

Viele Grüße
      Michael