Ist XML überbewertet?

*john 0

byto schrieb:

Wie willst Du denn sowas sinnvoll in eine flache CSV normalisieren:

<dokument>
  <person id="1">
    <vorname>Hans</vorname>
    <nachname>Meiser</nachname>
  </person>
  <person id="2">
    <vorname>Hans</vorname>
    <nachname>Wurst</nachname>
  </person>
  <verein>
    <mitglied ref="1" />
  </verein>
  <verein>
    <mitglied ref="1" />
    <mitglied ref="2" />
  </verein>
</dokument>

Wer im Glashaus sitzt sollte nicht mit Steinen werfen.

byto

Ich schrieb: "eine CSV". Deine angebliche Lösung umfasst drei CSV-Dateien. Das habe ich zuvor ausgeschlossen: "Willst Du pro Table eine CSV schicken?".

Spec: http://tools.ietf.org/html/rfc4180

otze

byto schrieb:

Spec: http://tools.ietf.org/html/rfc4180

While there are various specifications and implementations for the CSV format (for ex. [4], [5], [6] and [7]), there is no formal specification in existence, which allows for a wide variety of interpretations of CSV files. This section documents the format that seems to be followed by most implementations:

Toll. "Eigentlich macht das jeder so wie er will. Aber für meine Argumentation suche ich mir jetzt die Implementation raus, die passt."

*john 0

byto schrieb:

Ich schrieb: "eine CSV".

Und du hast eine bekommen! Die Tabellen werden durch Leerzeilen von einander getrennt, so daß man keine unterschiedlichen Dateien braucht.

byto

Und als nächstes schmeissen wir 3 JPGs in eine Datei und sagen es ist ein Bild?

TGGC

byto schrieb:

Und als nächstes schmeissen wir 3 JPGs in eine Datei und sagen es ist ein Bild?

Und wir schmeissen ein paar < und ein paar > in eine *.txt und behaupten es ist ein xml? f'`8k

Autocogito

Gruß, TGGC (Was Gamestar sagt...)

byto

Ja, Du hast Recht. Lasst uns alle nur noch unsere eigenen proprietären Formate benutzen und auf offene Standards scheissen. Macht ja auch viel mehr Spaß, die Parser und Tools jedes mal neu zu schreiben, statt fertige Lösungen zu benutzen. Der Kunde zahlt bestimmt auch gerne dafür, dass wir jedes mal das Rad neu erfinden.

Artchi

Solange man keine Daten austauscht, sind eigene Formate legitim. Schlecht ist es nur, wenn das eigene Format nicht so dokumentiert ist, das man es in ein Austauschformat umwandeln kann. Ich fand es ja bisher z.B. immer sehr amüsant, wie sich die halbe Welt über Microsofts Word-Format aufregt, obwohl MS immer offiziell ein dokumentiertes Austauschformat namens RTF hat.

Im übrigen, auch Austauschformate sind nicht immer sinnvoll. Das beste Beispiel ist doch ODF. Ein Format das speziell für OOo entwickelt wurde. Und wer ein Office entwickelt hat, das ganz andere Funktionen hat, dem hilft ODF nicht weiter. Ein Austauschformat kann nur einen gemeinsamen Nennen (Kompromiss) bilden. Alleine deshalb kommt man als Entwickler von Software, die Killer Features haben sollte, nicht um ein eigenes Format umhin.

Prof84

Artchi schrieb:

Solange man keine Daten austauscht, sind eigene Formate legitim. Schlecht ist es nur, wenn das eigene Format nicht so dokumentiert ist, das man es in ein Austauschformat umwandeln kann. Ich fand es ja bisher z.B. immer sehr amüsant, wie sich die halbe Welt über Microsofts Word-Format aufregt, obwohl MS immer offiziell ein dokumentiertes Austauschformat namens RTF hat.

Im übrigen, auch Austauschformate sind nicht immer sinnvoll. Das beste Beispiel ist doch ODF. Ein Format das speziell für OOo entwickelt wurde. Und wer ein Office entwickelt hat, das ganz andere Funktionen hat, dem hilft ODF nicht weiter. Ein Austauschformat kann nur einen gemeinsamen Nennen (Kompromiss) bilden. Alleine deshalb kommt man als Entwickler von Software, die Killer Features haben sollte, nicht um ein eigenes Format umhin.

Moment mal! ODF konnte erst entwickelt werden, weil MS seine Officedateiformate als in XML spezifiziert und freigab.
http://de.wikipedia.org/wiki/Office_Open_XML
Was mich bis heute wundert, denn damit gab MS seine Kronjuwelen frei außer Haus und zieht sich mit Open Office Konkurrenz.

Prof84 schrieb:

Und wehe Du brauchst mal einen Deutschen. - Kommt sofort Dagobert Duck im seiner alten Schrott-Büchse runter ...

Hey, jetzt reicht es aber ...
http://www.handelsblatt.com/technologie/schneller-schlau/schneller-schlau-wer-war-der-reichste-mensch-aller-zeiten;2476001

DEvent

Prof84 schrieb:

Artchi schrieb:

Solange man keine Daten austauscht, sind eigene Formate legitim. Schlecht ist es nur, wenn das eigene Format nicht so dokumentiert ist, das man es in ein Austauschformat umwandeln kann. Ich fand es ja bisher z.B. immer sehr amüsant, wie sich die halbe Welt über Microsofts Word-Format aufregt, obwohl MS immer offiziell ein dokumentiertes Austauschformat namens RTF hat.

Im übrigen, auch Austauschformate sind nicht immer sinnvoll. Das beste Beispiel ist doch ODF. Ein Format das speziell für OOo entwickelt wurde. Und wer ein Office entwickelt hat, das ganz andere Funktionen hat, dem hilft ODF nicht weiter. Ein Austauschformat kann nur einen gemeinsamen Nennen (Kompromiss) bilden. Alleine deshalb kommt man als Entwickler von Software, die Killer Features haben sollte, nicht um ein eigenes Format umhin.

Momaent mal! ODF konnte erst entwickelt werden, weil MS seine Officedateiformate als in XML spezifiziert und freigab.
http://de.wikipedia.org/wiki/Office_Open_XML
Was mich bis heute wundert, denn damit gab MS seine Kronjuwelen frei außer Haus und zieht sich mit Open Office Konkurrenz.

Was redest du da zusammen?

Prof84

DEvent schrieb:

Was redest du da zusammen?

Open Office hat nur deshalb die Akzeptanz, weil die Austauschformate kompatible zu den MS-Office Produkten sind, was Staroffice bis 2003/4 eben nicht war.

Deshalb konntest man einen ODF Standard entwickeln, der den Informationsgehalt des MS Kramm abbilden kann. Konnte er vorher eben nicht.
http://de.wikipedia.org/wiki/OpenOffice.org
http://de.wikipedia.org/wiki/Office_Open_XML

... und die in meinen Sekundärlink "XML hat keine Zukunft ...bla" von mir diskutierten Korrelation zwischen OO und XML wiedergespiegelt wurde.

DEvent

Prof84 schrieb:

DEvent schrieb:

Was redest du da zusammen?

Open Office hat nur deshalb die Akzeptanz, weil die Austauschformate kompatible zu den MS-Office Produkten sind, was Staroffice bis 2003/4 eben nicht war.

Deshalb konntest man einen ODF Standard entwickeln, der den Informationsgehalt des MS Kramm abbilden kann. Konnte er vorher eben nicht.
http://de.wikipedia.org/wiki/OpenOffice.org
http://de.wikipedia.org/wiki/Office_Open_XML

... und die in meinen Sekundärlink "XML hat keine Zukunft ...bla" von mir diskutierten Korrelation zwischen OO und XML wiedergespiegelt wurde.

Und ich verstehe immernoch nicht von was du redest.
Das alte DOC Format wurde lesbar gemacht durch reverse-engineering. Dann braucht aber OO.org immernoch ein eigenes Format um die Dokumente abzuspeichern, so wurde ODF erfunden. Dann wurde ODF standardisiert.

*john 0

byto schrieb:

Der Kunde zahlt bestimmt auch gerne dafür, dass wir jedes mal das Rad neu erfinden.

XML ist ja sooo toll. Woher soll die Applikation denn wissen, was ein Tag bedeutet? Wenn man in der Applikation nicht für ein ganz bestimmte DTD Unterstützung eingebaut hat, kann man zwar die XML-Dateien bearbeiten, aber ein automatisches Mappen auf interne Zustände der Applikation ist dann unmöglich. Hier gibt es also keinerlei Vorteil gegenüber einem anderem dokumentierten Datenformat!

byto

Wenn Du die Vorteile von XML gegenüber proprietären Lösungen nicht siehst, dann tuts mir echt leid für Deinen Arbeitgeber.

XML-Binding ermöglicht Dir aus einem Objektgraphen eine XSD automatisch zu generieren. Genauso ist der umgekehrte Weg möglich: Aus einer gegebenen XSD wird das Klassenmodell automatisch generiert. Bei Bedarf lässt sich das Klassenmodell natürlich auch per Hand schreiben und mit ein paar Metadaten an die XSD binden.
Zusätzlich gibts dann noch automatisches Marshalling / Unmarshalling zwischen XML und Objektgraph.

Darauf aufbauend existieren WS-Tools, um das durchs XML-Binding etablierte Austauschformat automatisch als Webservice per SOAP + WSDL als Schnittstelle zur Verfügung zu stellen.

Was bedeutet das für den Entwickler? Der Entwickler hat nichts weiter zu tun, als sein Domänenmodell zu pflegen. Die Schnittstelle kann ohne jeglichen Aufwand deklarativ eingestellt werden. Der Konsument der Schnittstelle kann wiederum die bestehenden Tools nutzen, um die empfangenen Daten in sein Domänenmodell zu integrieren.

volkard

byto schrieb:

Wenn Du die Vorteile von XML gegenüber proprietären Lösungen nicht siehst, dann tuts mir echt leid für Deinen Arbeitgeber.
XML-Binding...XSD...Klassenmodell...automatisches Marshalling... Objektgraph..WS-Tools...etablierte Austauschformat...SOAP + WSDL...
Schnittstelle deklarativ...Konsument der Schnittstelle...Domänenmodell!

Der Entwickler hat nichts weiter zu tun, als sein Domänenmodell zu pflegen.

Ahso! Ja, das hätte man mir auch mal gleich sagen sollen. Das vereinfacht natürlich alles.
Das Domänenmodell halte natürlich ich immer topaktuell, auch wenns manchmal mit einem generic logic planner ist.

Artchi

Komisch das dieses Konzept der autom. Generierung von Klassen aus Modellen absolut nichts mit XML zu tun hat. Das kann man mit jedem anderen Datenformat auch machen, z.B. IDL von DCOM oder CORBA. Und wahrscheinlich tausend anderen Formaten, die jeder Hinz und Kunz entwickelt hat.

byto

Komisch, dass ich das nie behauptet habe.

Abgesehen davon kenne ich kein anderes Format, wo die Binding Tools so gut entwickelt sind wie bei XML. CORBA ist ziemlich altbacken und die Tools längst nicht mehr state-of-the-art. DCOM ist nicht plattformunabhängig, daher für mich irrelevant. Nenn mal ein paar dieser "wahrscheinlich tausend anderen Formate", die ähnlich guten Toolsupport wie XML haben! Neben JSON (was ich ja schon mehrmals erwähnt habe) fällt mir da nicht viel ein. Aber das muss ja nichts heissen. Du scheinst Dich da ja ganz gut auszukennen bei den ganzen Formaten.

Ich setze sicher auch nicht für jeden scheiss XML ein. In meinem aktuellen Client-Server Projekt schicken wir z.B. Binärdaten über HTTP. Das ist schön schnell.

Für Schnittstellen über Systemgrenzen hinweg, wo der Performance Overhead durch XML nicht relevant ist, spricht für mich aber überhaupt nichts dagegen, XML als Austauschformat einzusetzen.

volkard

byto schrieb:

Ich setze sicher auch nicht für jeden scheiss XML ein. In meinem aktuellen Client-Server Projekt schicken wir z.B. Binärdaten über HTTP. Das ist schön schnell.

Das hat mit HTTP nichts zu tun. Über HTTP kann man sowohl Binärformate als auch XML schicken.

byto

Du hast mich nicht richtig verstanden. Das "schnell" bezog sich auf "binär".

Der Einsatz von HTTP(S) hat andere Gründe (SSL, Firewalls).

Prof84

Prof84 schrieb:

- Die 100ste Anfrage von EADS, ob nicht doch ihren AM400 als oberster Systemigenieur bzw Anforderungsmanager retten will. Absage meinerseits: Keine militärischen Projekte!
https://www.c-plusplus.net/forum/236252

Prof84 schrieb:

Marc++us schrieb:

Prof84 schrieb:

Im State-of-Art der Automationsprozesse HAT XML alle gängigen Hochsprachen abgelöst.

Nur mal zur Frage der Definition:

Meinst Du damit Automation in Softwareprozessen, oder in der Automatisierungstechnik?

Ist für mich gleichbedeutend mit der Frage, welchen Stellenwert SW in der Automationstechnik hat. Das kann man heutzutage nicht mehr so einfach trennen.

Für ein GRID für Fertigungstechnik, CNC Einstellung bestimmter Fertigungsmodule, ein Image für ein FPGA, Austausch Mess- und Steuerungstechnik bekommst Du bei den meisten Herstellern schon Dein redundanten XML Dump.

Ich weiß jetzt nicht wie es bei einer S6 aussieht. Aber ein Kollege von mir hat eine Firma in der Feinblechverarbeitungstechnik und einige Stanz-, Kant-, Biege, Dreh- und Lasermaschinen von Trumph stehen. Dort wird jede Werkzeugkonfiguration, jede Kopfeinstellung, jedes CNC Makro, jede Serienfahne als XML gespeichert. Das CAD-Programm dumped seinen XML aus und die Maschinen parsen den Kramm und bietet gleich das fertige Programm an. Zeitoptimiert, leerschnittopimiert, prozessoptimiert ... Die Gesamtkonfiguration kann man über Repositry beim Hersteller mit den aktuellesten Analyseprogrammen gleich auf Konsistenz prüfen lassen. Die Systeme sind mittlerweile so gut, dass sie gleich Sicherheitshinweise zu Werkzeugverschleiß, Temperaturentwicklung, Materialbeschaffenheit etc als 'Guidance in Context' über Webservice auf das Arbeitsterminal bringen. Und bei unendlich denkbaren Permutationen der Maschinenkonfiguration geht nur XMS (XML DBMS).
Also heute mit modernsten Maschinen 1.000 Teile Klumpen zu fahren ist schon verdammt schwer. Dafür musst Du gleich im den ersten Schritten im Büro Scheiße bauen (falsche Anforderungen oder so).

Während gerade EADS nach dem Desaster mit dem AM400 ihre kompletten Tool-Chains über XML aufbauen ohne das noch ein Mensch die Finger dazwischen hat, habe ich noch Altkunden, die sich ganze Zwergenarmeen halten, um händisch von einem Tool in das Nächste Daten zu übertragen, sich dann noch beschweren, dass sie über einen Monat brauchen um ein neuen Tarif anzulegen und es ständig knallt.

Letztes Jahr hatte ich noch mit ein R/3 Modul gearbeitet, beidem ich ein Controlling-Dump nur als Excel-Pivottabelle bekommen konnte. Obwohl SAP natürlich ein berechtigtes Interesse daran hat jeden offenen Standard zu meiden, um ihre Kunden doof im Vendor-Lockin zu halten.

Das passiert, wenn Sie nicht mit P84 fliegen :
http://www.handelsblatt.com/unternehmen/handel-konsumgueter/defekte-triebwerkssteuerung-a400m-wegen-software-problemen-abgestuerzt/11796124.html