Ist XML überbewertet?

byto

Scheppertreiber schrieb:

Immer diese Diskrepanz zwischen Theorie und Praxis ...

Die Praxis zeigt in vielen Fällen, dass es funktioniert. Aber es gibt natürlich immer DAUs, die mit Technologien nicht zurecht kommen. Damit muss man dann leider leben.
Lösungsvorschlag meinerseits: Definier doch ein striktes XSD-Schema für Eure XML-Struktur. Kommt dann eine Datei im falschen Format, kannst Du den schwarzen Peter weiterschieben.

nman

;fricky schrieb:

µngbd: endlich mal eine sinnvolle anwendung für die lisp-syntax *fg*

Zum Glück gibt es Dich und c++.de und somit nach fünfzig Jahren endlich eine gute Anwendung für die Lisp-Syntax, sonst hätten wir Ärmsten bestimmt noch weitere fünfzig Jahre gewartet. Hoch fricky! Unser Erlöser!

Scheppertreiber

Hi byto,

da spielen auch noch andere Faktoren wie Laufzeit eine Rolle.

Klar kann ich einen XML-Parser einsetzen ...

Im Extremfall kann ich auf die Buchungssätze ganz verzichten und parse das PDF.
Lesen und ablegen muß ich es eh. Ich bin dafür, XML da einzusetzen wo es sinnvoll
und vertretbar ist. Es hat aber halt auch Nachteile.

Tags mit Umlauten sind lustig. XML mit dem IE anschauen ist lustig. Was man da manchmal
an Daten bekommt reizt zu Lachkrämpfen

byto schrieb:

;fricky schrieb:

zwutz schrieb:

Würde er Binärdaten schicken müsstet ihr euch erstmal auf ein Format einigen oder du dürftest jedesmal den Parser anpassen.

binärdaten kann man in textformaten z.b. als 'base64' unterbringen. sowas wird oft gemacht und stellt keinen vor probleme.

Und dann? Hast Du immernoch ein Binärformat ohne feste Struktur.

ich meinte ja auch nicht base64 als ersatz für XML. man kann z.b. base64-kodierte binärdaten in XML-elemente oder in CDATA-bereiche stecken.

Scheppertreiber

Lieber base13,8 - kriegt keiner raus was da versteckt ist

zwutz

;fricky schrieb:

ich meinte ja auch nicht base64 als ersatz für XML. man kann z.b. base64-kodierte binärdaten in XML-elemente oder in CDATA-bereiche stecken.

darf ich derzeit machen. Beliebige Dateien sollen zusammen mit ein paar Metainformationen über eine Schnittstelle verschickt werden, die nur mit Textdateien umgehen kann. XML war dabei die Vorgabe, ich hätts in dem Fall wohl eher nicht hergenommen

byto

Scheppertreiber schrieb:

da spielen auch noch andere Faktoren wie Laufzeit eine Rolle.

Klar, aber es gibt extrem leistensfähige XML Parser.

Tags mit Umlauten sind lustig. XML mit dem IE anschauen ist lustig. Was man da manchmal
an Daten bekommt reizt zu Lachkrämpfen

Tags mit Umlauten sind kein Problem, sofern das Encoding angegeben ist. Und zum IE... der ist nicht mal für Webseiten geeignet. Warum sollte man sich damit also XML Dateien angucken?

;fricky schrieb:

µngbd: endlich mal eine sinnvolle anwendung für die lisp-syntax *fg*

nman schrieb:

Zum Glück gibt es Dich und c++.de und somit nach fünfzig Jahren endlich eine gute Anwendung für die Lisp-Syntax, sonst hätten wir Ärmsten bestimmt noch weitere fünfzig Jahre gewartet. Hoch fricky! Unser Erlöser!

Hmm, ich werde den Veracht nicht los, dass alle die esoterischen Vorzüge, die man Lisp nachsagt, irgendwie mit meinem Beispiel zu tun haben. Lisp ist eben nicht nur eine Programmier- sondern auch eine Beschreibungs-Sprache.

Übrigens hab ich schon die ein oder andere Website mit XML gemacht und mit Saxon & XSLT erzeugt. Da kann man schön mit Umlauten oder anderem Kodierungs-Käse umgehen. Auch Python hat Bibliotheken für XML, und ich hatte mit diesen Dingen noch nie XML-Probleme.

Wenn man übrigens einen Interpreter für XYZ dort am Laufen hat, wo man die Daten einliest, kann man auch gleich Anweisungen für den Interpreter als Datenformat verwenden. Das hab ich mal in dem Lua-Buch gelesen:

lieferschein (
  nummer ("00000815"),
  datum (1256633179),
  empfänger (
    name ("Dr. Foo"),
    vorname ("Hans"),
    plz ("01337"),
    ort ("Musterdorf"),
    straße ("Baumstraße 3")
  )
)

Wenn man die Zeilen in diesem Format hat, braucht man nur die entsprechenden Funktionen in XYZ definieren, und die Daten als Programm behandeln.

dv_

Ich sehe schon die glorreichen Videostream-Containerformate, die die Videodaten als Base64 in XML stecken.

Oder mein persönlicher Liebling: Spiele-Level-Informationen in XML, anstatt einen Binärdump zu haben, den man beim Laden mit einem einzigen Read komplett ins VRAM bekommt. Ja, ich habe solche XMLs bereits gesehen.

volkard

dv_ schrieb:

Ich sehe schon die glorreichen Videostream-Containerformate, die die Videodaten als Base64 in XML stecken.

Kar, es gibt den Film, darin die Videospuren und Tonspuren, in den Videospuren Sync-Abschnitte, innerhalb derer Bilder und innerhalb derer Zeilen und darin Pixels. Was anderes, als XML geht für so baumartig-hierarchische Daten gar nicht! Außerdem ist das praktisch die einzige Möglichkeit, auf PCs, MACs und Linux so einen FIlm abzuspielen, gar nicht an Nicht-PC-Hardware zu denken. Was man da für unendliche Mühen bei Binärformaten hat wegen der endianess und weil das Ende der Datei fehlt. Ok, man kann nicht mehr im Bild eine DCT machen oder über den Zeitverlauf packen, nur noch den XML-text. Aber was solls? Dann nimmt auch das elende Raubkopien wieder ein wenig ab, wenn man pro Film einen Koffer voller Terabyteplatten braucht.

DEvent

Man nimmt einfach das wozu es die passenden Werkzeuge gibt. Die Konfiguration in meinen Programmen speichere ich auch als XML, aber nur weil es XStream gibt.

XStream stream = new XStream();
sream.toXML(config);
// ...
config = stream.fromXML(filename);

Wie speichert man den Meta-Informationen in JSON/Lisp ab? Also sowas hier, da muss man doch extra Eintraege dafuer machen?

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

rüdiger

µngbd schrieb:

zwutz schrieb:

Einen XML-Parser hat man meist schon rumliegen, was man von anderen Textformaten nicht unbedingt behaupten kann).

Und? Lisp-Parser gibt es seit der Steinzeit, und niemand verwendet die. Obwohl schon einige bemerkt haben, dass S-Expressions das gleiche sind wie XML.

Ne, SEXPs sind nicht das gleiche. XML ist eben eine Markupsprache und hat daher Attribute. Deshalb wird ja alles noch einmal extra kompliziert, wenn man XML als Datensprache missbraucht.

Scheppertreiber

Ok, dann ist eher M$-FrontPage das ultimative Format. Es kann so richtig schön bunt, ist
genauso WischiWaschi und anfällig gegen alles. Und kann alles. Für BWLer ideal

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.