Hochgelobtes XML

[pl]

Halo und schön guten Morgen,

es gibt tolle Parser, die sind jedoch nicht überall verfügbar. Nun, der Vorteil von XML ist ja, dass Daten recht einfach überall verfügbar gemacht werden können. Da muss ja auch irgendwo ein Algorithmus beschrieben sein, wie XML maschinell zu parsen ist. Ich kann die RFC leider nicht finden, evntl. sind die Algorithmen ja auch woanders beschrieben.? Bitte mal um Hinweise. pl

[woodfighter]

Tach,

es gibt tolle Parser, die sind jedoch nicht überall verfügbar.

Für mehr als eine Übung, mich in das Thema einzuarbeiten, würde ich allerdings trotzdem nicht einen eigenen Parser verwenden, sondern etwas an dem Umstand ändern, dass ich essentielle Libs nicht nutzen kann.

Da muss ja auch irgendwo ein Algorithmus beschrieben sein, wie XML maschinell zu parsen ist.

ja, an diversen Orten; du solltest dich zum Suchen darauf festlegen, welchen Typ XML-Parser du schreiben möchtest (DOM, SAX, Pull; validierend oder nicht).

Ich kann die RFC leider nicht finden, evntl. sind die Algorithmen ja auch woanders beschrieben.?

Es gibt keine RFC dazu. Hier findest du eine Beschreibung eines nicht-validierenden DOM-Parsers: http://aosabook.org/en/posa/parsing-xml-at-the-speed-of-light.html und hier sind die DOM-Spezifikation des W3C: http://www.w3.org/DOM/DOMTR.

mfg
Woodfighter

[pl]

Tach,

Es gibt keine RFC dazu. Hier findest du eine Beschreibung eines nicht-validierenden DOM-Parsers: http://aosabook.org/en/posa/parsing-xml-at-the-speed-of-light.html und hier sind die DOM-Spezifikation des W3C: http://www.w3.org/DOM/DOMTR.

Ah, Lexer, Parser, Tokenizer. Ok. Guck ich mir mal an, gelegentlich...

PS: Falls die entsprechenden Libs fehlen, helfen RegEx, hier ein Einzeiler für den ForumFeed:

my $xml = get "https://forum.selfhtml.org/all.rss";
my @stash = map{{ /<(\w+)>(.*?)</sg }} @{[ $xml =~ /<item>(.*?)<\/item>/sg ]} ;

# @stash passend zu HTML::Template;

Aber ds war ja nich die Frage ;)

Schönes Wochenende.

[woodfighter]

Tach,

PS: Falls die entsprechenden Libs fehlen, helfen RegEx, hier ein Einzeiler für den ForumFeed:

RegEx sind im Allgemeinen eine wirklich schlechte Idee um XML/HTML zu parsen.

mfg
Woodfighter

[pl]

Gelegentlich lohnt es sich auch darüber nachzudenken, die Daten nach alten bewährten Verfahren (Niklaus Wirth) weniger umständlich, mit weniger Bandbreitenbedarf sowie CPU- und RAM-gefälliger zu verpacken. Das braucht dann weder XML noch RegEx.

[Gunnar Bittersmann]

@@pl

Gelegentlich lohnt es sich auch darüber nachzudenken, die Daten nach alten bewährten Verfahren (Niklaus Wirth) weniger umständlich, mit weniger Bandbreitenbedarf sowie CPU- und RAM-gefälliger zu verpacken. Das braucht dann weder XML noch RegEx.

Du denkst an JSON?

Vermutlich nicht, da du noch ein neues Rad erfinden willst.

LLAP 🖖

[pl]

Der Spruch mit dem neuen Rad ist bescheuert. Es gibt Serialize-Algorithmen die sind bei Weitem zweckmäßiger als XML und die gab es viele Jahre vor XML (JSON inbegriffen).

XML einer Maschine beizubringen ist sehr aufwändig. Lexer, Parser, Tokenizer, das sind Begriffe die kommen aus der Welt der Compiler. Von wegen einfach zu implementieren.

[Gunnar Bittersmann]

@@pl

Der Spruch mit dem neuen Rad ist bescheuert.

Mag sein. Stammt aber nicht von mir.

Es gibt Serialize-Algorithmen die sind bei Weitem zweckmäßiger als XML

Äpfel? Birnen? Wie kann ein Algorithmus zweckmäßiger sein als ein Format?

XML einer Maschine beizubringen ist sehr aufwändig. Lexer, Parser, Tokenizer, das sind Begriffe die kommen aus der Welt der Compiler. Von wegen einfach zu implementieren.

Ganz einfach: Man nimmt einen der schon entwickelten XML-Parser. Das isses wieder, das Rad.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Es gibt Serialize-Algorithmen die sind bei Weitem zweckmäßiger als XML

Äpfel? Birnen? Wie kann ein Algorithmus zweckmäßiger sein als ein Format?

Nitpicking. Was pl meint ist IMHO offensichtlich, und ich stimme ihm im wesentlichen zu. XML ist ein Fall von XKCD #927 ;-) ansonsten ist zu dem Thema Erik Naggum's Rant über XML äusserst empfehlenswert zu lesen.

XML einer Maschine beizubringen ist sehr aufwändig. Lexer, Parser, Tokenizer, das sind Begriffe die kommen aus der Welt der Compiler. Von wegen einfach zu implementieren.

Ganz einfach: Man nimmt einen der schon entwickelten XML-Parser. Das isses wieder, das Rad.

Da ist nichts dran einfach. Es ist einfacher als einen eigenen XML-Parser zu schreiben, aber auch die Verwendung von XML-Parsern ist und bleibt komplex. Und XML selber bietet auch so viele Fallstricke… von der Abhängigkeit, die man sich ins Boot holt sowie der zusätzlich geschaffenen Maintenance-Notwendigkeit möchte gar nicht erst anfangen.

LG,
CK

[pl]

hi,

Äpfel? Birnen? Wie kann ein Algorithmus zweckmäßiger sein als ein Format?

Genau hier liegt Dein Missverständnis. Ein Algorithmus erzeugt aus einer Datenstruktur eine Sequenz.

Die Datenstruktur (Hash, array, struct...) dient dem wahlfeien Zugriff innerhalb eines Programms. Die Datei dient dem Transport außerhalb eines Programms (Dateisystem, IO, Sockets, HTTP, FTP usw.).

Zu diesen Grundlagen, die N. Wirth in den 80ern geprägt hat, gehört die Feststellung, dass ein wahlfreier Zugriff nicht auf Dateiebene abgebildet wird, sondern über o.g Datenstrukturen.

Das Format der Datei nennen wir besser Content-Type. Und obenstehendes Schichtenmodell konsequent angewandt heißt, dass es für den Random Access völlig egal ist, mit welchem Content-Type die Datei übertragen wurde.

D.h., letztendlich ist ein Content-Type: application/xml einem Content-Type: application/octet-stream gleichberechtigt und somit vom Programm abstrahiert. pl

[1unitedpower]

Die Datenstruktur (Hash, array, struct...) dient dem wahlfeien Zugriff innerhalb eines Programms. Die Datei dient dem Transport außerhalb eines Programms (Dateisystem, IO, Sockets, HTTP, FTP usw.).

Dateien, Ordner und Archive bilden eine Metapher um Menschen eine anschauliche Vorstellung von persistenten, digitalen Daten zu bieten. Unter Fachleuten muss man nicht notwendigerweise an dieser Metapher festhalten, wenn es der Sache eher im Wege stünde. Es ist zum Beispiel hinderlich eine HTTP-Anfrage oder -Antwort als Datei zu betiteln, weil der Kommunikation dann ein Teil des Kontextes verloren geht. Ähnliches gilt für Sockets: Man kann Anfängern eine Socketschnittstelle als Parellele zu Dateizeigern erklären, im Gespräch mit fortgeschrittenen Entwicklern sollte man zwecks Präzision und Expressivität direkt das spezifischere Vokabluar verwenden, also das Kind beim Namen nennen.

Es ist für andere Entwickler schwer dir zu folgen, wenn du alles in Begrifflichkeiten von Dateien und Sequenzen erklärst, anstatt auf allgemein bekanntes Fachvokabluar zurück zu greifen. Und präzise bedeutet nicht unbedingt low-level. Du würdest ja auch nicht auf die Idee kommen, ein Fußballspiel auf molekularer Ebene zu moderieren: Statt "Rahn schießt! – Tooooor! Tooooor! Tooooor! Tooooor!" jubelst du nicht "Die langkettigen, ioniersten Aminosäuren reagieren mit den hydrophoben, anorganischen Plasmen! – Photosynthese! Photosynthese! Photosynthese! Photosynthese!" (der aufmerksame Biochemiker hat natürlich gemerkt, um welches Spiel es sich hier handelt).

[Der Martin]

Hallo,

Es ist für andere Entwickler schwer dir zu folgen, wenn du alles in Begrifflichkeiten von Dateien und Sequenzen erklärst, anstatt auf allgemein bekanntes Fachvokabluar zurück zu greifen.

das ist alles richtig, ich kenne ähnliche Probleme aus meinem eigenen Umfeld: Wenn meine Mutter irgendein "Problemchen" am PC erklärt haben möchte, benutzt sie auch gern Fachausdrücke, die sie irgendwann mal aufgeschnappt hat. Nur benutzt sie die natürlich mangels Hintergrundwissen gern falsch oder in einem falschen Kontext, so dass sie es mir damit nicht gerade leichter macht, ihr zu folgen. Im Gegenteil.

So long,
 Martin

[Tim Tepaße]

Da muss ja auch irgendwo ein Algorithmus beschrieben sein, wie XML maschinell zu parsen ist. Ich kann die RFC leider nicht finden, evntl. sind die Algorithmen ja auch woanders beschrieben.? Bitte mal um Hinweise. pl

XML wurde vom W3C spezifiziert, die Spezifikation von XML 1.0 5th Edition ist natürlich auch dort zu finden.

Du siehst dort im Text immer Produktionen ähnlich der Backus-Naur-Form wie auch in RFCs, zusammen geben die ein grobes Bild der Struktur von XML-Dokumenten für die man seinen XML Prozessor baut. Hier die erste, die die sehr, sehr, sehr grobe Großstruktur von XML definiert, die einzelnen Teilstücke verweisen dann auf folgende verschachtelte weitere Definitionen.

[1]  document  ::=  prolog element Misc*

Allerdings reicht das nicht. Es gibt diverse Anforderungen an XML Prozessoren, die sich nicht mit BNF ausdrücken lassen, zum Beispiel das Auflösen von definierten Entities, die Behandlung von Zeilenumbrüchen, die Erkennung von UTF-8 oder UTF-16 bei Abwesenheit der Deklaration von Charset, die Fehlerbehandlung bei nicht Wohlgeformtheit und vieles mehr. Es empfiehlt sich also, die Spec wie üblich zu lesen, mehrmals von vorne, mindestens einmal von hinten, dann randomisiert …

Es gibt auch noch ein XML 1.1, allerdings kann man das ignorieren. Die Änderungen betreffen u.a. größtenteils EBDIC-Kompabilität für IBM-Systeme und die Änderungen, welche Unicode-Zeichen erlaubt sind, wurden von XML 1.1 in die 5th Edition übernommen.

Das XML-Ökosystem ist seit 1998 natürlich gewachsen. Eher nicht ignorieren sollte Dein Parser XML Namensräume, Behandlung dafür solltest Du also inkorporieren; schließlich sind die ein wesentlicher Bestandteil moderner XML-Dialekte. Es gibt auch Attribute, die in jedem XML-Dokument legal sind. Neben dem in XML 1.0 definierten xml:lang gibt es xml:id und xml:base; bei letzterem braucht es natürlich auch den entsprechenden RFC für die Auflösung relativer URLs im base-Kontext. Beim Organisieren Deiner Datenstrukturen ist eventuell auch noch XML Infoset praktisch.

Nachgetragen: Natürlich willst Du dann Deinen Parser auch auf Richtigkeit testen, das W3C unterhält eine Suite von knapp 2000 Testdokumenten.

Viel Spaß!