Ist XML überbewertet?

Prof84

http://www.c-plusplus.net/forum/viewtopic-var-t-is-22790-and-highlight-is-.html

Womit bewiesen ist, dass ich wahrscheinlich bereits vor sechs Jahren mehr über XML wusste als heute das gesamte Forum. Und es wahrscheinlich auch bewiesen ist, dass es Einige hier heute wie damals wohl noch nicht gelernt haben ...

Angelea Merkel schrieb:

"In der Wissenschaft sind Sie es gewohnt eine Thema erst dann wieder zu Sprache zu bringen, wenn es was Neues gibt. In der Politik müssen Sie sich ständig wiederholen. Und erst dann wenn Sie es resigniert aufgeben, ist es gerade mal beim Ersten durchgedrungen!"

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

Prof84 schrieb:

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

ehrlich? kann man jetzt auch schon xml-parser in xml schreiben?

Prof84 schrieb:

Womit bewiesen ist, dass ich wahrscheinlich bereits vor sechs Jahren mehr über XML wusste als heute das gesamte Forum.

^^stimmt, das forum besteht ja auch nur aus PHP. *fg*

Bashar

Prof84 schrieb:

http://www.c-plusplus.net/forum/viewtopic-var-t-is-22790-and-highlight-is-.html

Womit bewiesen ist, dass ich wahrscheinlich bereits vor sechs Jahren mehr über XML wusste als heute das gesamte Forum.

Wozu musst DU etwas beweisen, dir glaubt man doch auch so jedes Wort.

Marc++us

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?

Prof84

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.

Scheppertreiber

Hi Prof84,

so ein System kann man auch ohne XML realisieren - klar.

XML ist da nur ein Datenformat, sonst nichts. Da steckt etwas mehr dahinter.

XML hat sich so weit verbreitet, weil die Leute es lieben Sachen baumartig zu strukturieren und weil Parser geschrieben wurden. DAS sind die Hauptgründe an denen es nix zu zweifeln gibt. Amen.

Marc++us

Ich habe jetzt wieder Verschiedenes verstanden.

Kleine Anekdote:

XML-Protokoll zwischen zwei Lieferanten. Lieferant A implementiert das Protokoll so, daß er nur mit den ihm wichtigen(!) Attributen klarkommt. Sendet Lieferant B mal ein XML-Telegramm (das wohlgeformt) ist mit anderen Attributen - Crash. Komplette Anlage down. Hat den XML-Parser anscheinend über Stringparsing realisiert.

Kleine Anekdote:

XML-Protokoll zwischen zwei Lieferanten. In der Spec steht das XML-Protokoll formatiert, zur besseren Lesbarkeit. Kommunikationstest. Nichts geht. Nach längerer Fehlersuche stellt man fest, daß Lieferant B DIE ZEILENUMBRÜCHE ERWARTET. Ohne den Zeilenumbruch an der richtigen Stelle funzt der XML-"Parser" nicht.

Maschinendatenkonsistenzprüfung:

Voraussetzung ist eine ordentliche Simulation des Tools. XML ist in diesem Szenario gar nix. Es ist nicht wertschöpfend in dieser Konfiguration, da jede Vereinbarung über das Datenformat die gleiche Information transportiert hätte. Begründung der Notwendigkeit liegt also in einer anderen Dimension.

Marc++us

Prof84 schrieb:

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.

"get better dwarfs"

Gsemmel schrieb:

XML hat sich so weit verbreitet, weil die Leute es lieben Sachen baumartig zu strukturieren...

ja, das ist z.b. auch das erfolgsrezept von spielen wie 'tetris'. man appelliere einfach an den menschlichen ordnungssinn.

Marc++us schrieb:

...Komplette Anlage down. Hat den XML-Parser anscheinend über Stringparsing realisiert.
...Ohne den Zeilenumbruch an der richtigen Stelle funzt der XML-"Parser" nicht.

ist aber kein prinzipielles problem von XML, wenn leute selbstgestickte, schrottige parser verwenden.

Scheppertreiber

... gabz zu schweigen von schrottigen XML-Generatoren

Scheppertreiber schrieb:

... gabz zu schweigen von schrottigen XML-Generatoren

jaja, immer dieses 'not invented here'-syndrom. dabei gibts, gerade was XML angeht, viele fertige und 1000fach getestete open-source lösungen, z.b. von 'apache'. aber nein, da fummeln sie sich lieber selber parser und generatoren hin und meckern dann rum, dass XML mist ist. *fg*

Scheppertreiber

Klar. Aber wer hat Recht ? Der Kunde ?

byto

Dass man sich bei bestimmten Kunden häufig mit technischen Krücken rumschlagen muss, ist ja nichts Neues. Das ist ja nun keine Eigenheit von XML. Nächstes Mal ist es ein grottiges DB-Schema oder ein inkonsistentes Pflichtenheft.

Wer Recht hat? Natürlich Du als schlauer Entwickler, der es besser weiss. Aber das musst Du dem Kunden ja so nicht sagen.

Scheppertreiber

So ist es. Rache per Rechnung

Nee, XML ist nicht für den Unsinn verantwortlich der damit angestellt wird. Das Einzige
was mich daran stört ist die aufgeblähte Syntax mit den Monster-Tags. Es bläst die Datenmenge
unnötig auf. Speziell das Ende-Tag hätte etwas sparsamer ausfallen können.

EXDW

ausgeblaeht ?

variante 1:

<lieferschein> 
  <nummer length="8">815</nummer> 
  <datum format="dd.mm.YYYY">1256633179</datum> 
  <empfänger> 
    <name sortkey="foo">Dr. Foo</name> 
    <vorname sortkey="hans">Hans</vorname> 
    <plz>01337</plz> 
    <ort>Musterdorf</plz> 
    <straße>Baumstraße 3</straße> 
  </empfänger> 
</lieferschein>

variante 2:

<lieferschein> 
  <nummer length="8" var="815" />
  <datum format="dd.mm.YYYY" var="1256633179" />
  <empfänger>
    <name sortkey="foo" var="Dr. Foo" />
    <vorname sortkey="hans" var="Hans" />
    <plz var="01337" />
    <ort var="Musterdorf" />
    <straße var="Baumstraße 3" />
  </empfänger> 
</lieferschein>

variante 3:

<lieferschein><nummer length="8" var="815" /><datum format="dd.mm.YYYY" var="1256633179" /><empfänger><name sortkey="foo" var="Dr. Foo" /><vorname sortkey="hans" var="Hans" /><plz var="01337" /><ort var="Musterdorf" /><straße var="Baumstraße 3" /></empfänger></lieferschein>

to be continued...

fuer ne machine is das alles egal #gg
wenn man sich auf etwas einigt kann xml schon schlank sein

volkard

815;1256633179;"foo";"Dr. Foo";"hans";"Hans";01337;"Musterdorf";"Baumstraße 3"

CSV 79 Byte gegenüber 275 des "optimierten" XML. Ist an sich egal, aber wage es nicht, XML "schlank" zu nennen.

EXDW

doch - das behaupte ich (man bermerkt das "kann")

dein beispiel angepasst:

csv:
815;1256633179;"foo";"Dr. Foo";"hans";"Hans";01337;"Musterdorf";"Baumstraße 3"

xml:
<item>815;1256633179;"foo";"Dr. Foo";"hans";"Hans";01337;"Musterdorf";"Baumstraße 3"</item>

der vorteil von dem "ausgeblaehten" xml ist gegenueber dem csv das die elemente in der reihenfolge geaendert werden koennen ohne das sich das ergebnis aendert
und es koennen weitere informationen dabei sein
in dein csv beispiel fehlt zb die laenge, das format und der sort key

bau diese information mal in dein csv ein

byto

volkard schrieb:

815;1256633179;"foo";"Dr. Foo";"hans";"Hans";01337;"Musterdorf";"Baumstraße 3"
CSV 79 Byte gegenüber 275 des "optimierten" XML. Ist an sich egal, aber wage es nicht, XML "schlank" zu nennen.

Für Schnittstellen und hierarchische Daten leider ungeeignet. Morgen vertauscht jemand plötzlich stillschweigend zwei Spalten in der CSV. Schon funktioniert die Schnittstelle nicht mehr. Im schlimmsten Fall fällts nicht mal auf.

Edit: Und wenn Du das XML schon "optimierst", dann mach doch einfach die Tagnamen kürzer. Schon ist die XML deutlich kleiner.

volkard

Mr Evil schrieb:

in dein csv beispiel fehlt zb die laenge, das format und der sort key

sortkey war drin.

Mr Evil schrieb:

bau diese information mal in dein csv ein

leider kein bedarf.

der csv-leser wird aber beim datum "1256633179" auch aussteigen, fürchte ich.