XML-basierte Programmiersprachen


8

Ich habe mir Wikipedia angesehen - Kategorie: XML-basierte Programmiersprachen .

Warum sollte jemand diesen Ansatz für das Entwerfen einer Sprache wählen?
Was sind die Vorteile davon?

Ich kann nur an Nachteile denken.

  • schwer zu pflegen
  • schwer zu lesen
  • schwer zu schreiben

2
Man hat normalerweise ein anderes Programm (visuelle Schnittstelle oder ähnliches), das ein Nicht-Programmierer verwendet, um etwas zu tun, das dann als XML gespeichert und als XML verarbeitet wird.

2
Ich stimme Ihren Nachteilen zu. Verwenden Sie Coldfusion und die Argumente, die Sie dagegen vorbringen, sind sehr klar.
Rig

@ Rig: Obwohl Coldfusion nicht in der Liste enthalten ist, auf die OP verweist.
FrustratedWithFormsDesigner

Ich nehme an, ein möglicher Vorteil wäre, dass ein solches System XQuery- und XPath-Abfragen und -Ausdrücke verwenden könnte, um das Schreiben von selbstmodifizierendem Code zu vereinfachen. Ob selbstmodifizierender Code, der über XPath / XQuery funktioniert, eine gute Sache ist oder nicht, kann diskutiert werden ...
FrustratedWithFormsDesigner

1
@ Mhd.Tahawi: Wenn Ihr Programmcode als gültiges XML geschrieben ist, kann Ihr Programm XPath / XQuery verwenden, um eine Reflexion über sich selbst durchzuführen. In Verbindung mit XSLT kann möglicherweise eine XML-basierte Programmiersprache entworfen werden, die XSLT zum Schreiben von Programmen verwendet, die sich selbst ändern können. Ich bin mir nicht sicher, ob ich mich mit einem solchen Programm befassen möchte, aber es könnte aus neuartiger Sicht cool sein.
FrustratedWithFormsDesigner

Antworten:


4

Einer der größten Vorteile einer XML-basierten Sprache besteht darin, dass sie einfach zu implementieren ist

Nein, es gibt eine Menge validierender Parser , die die syntaxbezogenen Kompilierungsfehler diagnostizieren und Ihnen den AST kostenlos zur Verfügung stellen

Die Ausführung iteriert auch einfach über den AST und führt eine Karte der Funktionen und Variablen


3
"Seem" ist hier das Schlüsselwort. Die Wahrheit ist, dass diese Vorteile entweder ziemlich klein oder nicht vorhanden sind, aber es scheint sicherlich so, wenn Sie noch nie eine Sprachimplementierung erstellt haben. Das Parsen ist rechenintensiv, aber tatsächlich einer der einfacheren Teile (Parser-Generatoren oder handgeschrieben) und das Design (Syntax ist billig). Und sobald Sie den AST haben, wird die Vorgehensweise nicht davon beeinflusst, wie Sie analysieren. Wenn die Ausführung einfach ist, bleibt es einfach, wenn Sie eine andere Syntax wählen (natürlich nur, wenn Sie die Semantik beibehalten).

@ Delnan Genau. Das einzige, was XML Ihnen kostenlos zu bieten scheint, ist der einfache Teil. Ich sage "scheint", weil es Ihnen eigentlich nichts gibt, es entweder nur auf den Benutzer überträgt oder eine Art (wahrscheinlich komplizierte) benutzerdefinierte GUI.
Evicatos

10

Code ist Daten.

Programme sind Daten. Eine Quelldatei ist nur eine bestimmte Serialisierung dieses Programms. Diese Idee ist zB in homoikonischen Sprachen wie Lisp verbreitet. Eine solche Sprache beseitigt die Barrieren zwischen dem Programmcode und den Daten, mit denen er arbeitet. Dies kann äußerst kraftvoll und ausdrucksstark sein, obwohl ich das Erscheinungsbild von Lisp-Code nicht als „schön“ oder „leicht zu lesen“ bezeichnen würde.

XML ist das strukturierte Datenserialisierungsformat für den aktuellen Unternehmensprogrammierer. Es gibt große Toolchains rund um die XML-Verarbeitung.

  • Aufgrund dieser Homoikonizität kann es interessant sein, eine Sprache zu definieren, die XML in XML verarbeiten soll. Ein Beispiel ist XSLT. Theoretisch erlaubt dies eine Metaprogrammierung, aber keine vernünftige Person würde dies tun, oder?
  • Vorlagensprachen sind an einer geringen Trennung zwischen Daten und Code interessiert. Die Verwendung eines XML-Dokuments als Vorlage / Programm ist interessant, wenn die Ausgabe XML oder HTML ist.
  • Das Speichern von Code einer Allzwecksprache in XML kann immer noch interessant sein. Das Speichern eines abstrakten Syntaxbaums, der anstelle von Quellcode in XML serialisiert wurde, ist sinnvoll, wenn dieser Code über eine IDE bearbeitet wird, wo er in einer besser lesbaren Form dargestellt wird, z . B. für die visuelle Programmierung . Dies ist nicht anders als in Smalltalk-Umgebungen, in denen der „Quellcode“ nur eine Darstellung des tatsächlichen Bytecode-Bildes ist.

Interessanterweise werden XML-Dokumente manchmal zum Vorlagen von Code verwendet … * shudder * (Abhängigkeitsinjektion). Ich schreibe dies der Allgegenwart von XML in einigen Toolchains zu / das Mindshare-XML als strukturiertes Datenformat.


1
Das Zusammenführen von Code mit Daten ist kein Vorteil. Es ist eine Sicherheitslücke auf Sprachebene. Das klassische Beispiel ist die SQL-Injection: Jedes Mal, wenn eine Site gehackt wird und Schäden im Wert von mehreren Millionen Dollar angerichtet werden und Zehntausende Benutzer aufgrund eines SQL-Injection-Exploits neue Kreditkarten bestellen müssen, liegt der Hauptgrund darin, dass ein Entwickler irgendwo festgelegt hat eine Abfrage auf eine Weise starten, bei der Daten nicht ordnungsgemäß vom Code getrennt wurden. Das Herumwerfen ausgefallener Wörter wie "Homoikonizität" ändert nichts an dieser fundamentalen Tatsache.
Mason Wheeler

5
@MasonWheeler Ich bin überhaupt nicht anderer Meinung, dass aus Sicherheitsgründen für jedes Templating-System ein ordnungsgemäßes Entkommen erforderlich ist, aber dies hat nichts mit der Frage, meiner Antwort oder der Trennung von Datencode zu tun. Ich flippe nicht über die rwxSkripte aus, die ich habe, die Daten für meinen Editor sind, sondern ausführbaren Code für meine Shell.
Amon

1
Die Tatsache, dass Sie versuchen, darauf zu reagieren, indem Sie in erster Linie entkommen - was der falsche Weg war und war, um eine SQL-Injection zu verhindern - und nicht in Bezug auf die Trennung von Code von Daten über Parameter - das heißt der einzig richtige Weg, dies zu tun - zeigt, dass Sie das Problem wirklich nicht verstehen. Und deshalb kommt es immer wieder zu SQL-Injection-Angriffen: Die Leute verstehen immer wieder nicht, warum diese Dinge wichtig sind und wie man sie richtig macht.
Mason Wheeler

7
@MasonWheeler: Ihre Kritiker der "Zusammenführung von Code mit Daten" sind richtig, wenn Sie Daten aus externen Quellen abrufen und daraus Code erstellen (was für XML übrigens in keiner Weise speziell ist). Diese Antwort hat jedoch einen völlig anderen Schwerpunkt. Es geht um den Aspekt der Metaprogrammierung.
Doc Brown

6
@MasonWheeler, Injection führt Daten aus, die nicht ausgeführt werden sollen. Homoikonizität bedeutet, dass Code und Daten in wörtlicher Form und in programmatischer Manipulation sehr ähnlich sind. Eine homoikonische Sprache kann vertrauenswürdige Daten sicher manipulieren und ausführen (aus ihnen generierter Code), sei es in Ihrem Quellcode fest codiert oder auf andere Weise. In z. B. Common Lisp können Sie Daten in generierten Code aufnehmen, ohne dass sie ausgeführt werden, z (eval `(foo (quote ,data))). Ihr Argument über Parameter vs. Escape mag richtig sein, aber Sie haben den Punkt verfehlt.
Acelent

2

Ich werde mich eher auf XSLT als auf XML-basierte Sprachen im Allgemeinen konzentrieren.

Natürlich gibt es hier eine Geschichte. XSLT wurde als Nachfolger von DSSSL, der Styling-Sprache für SGML, konzipiert und versuchte, das zu korrigieren, was DSSSL falsch gemacht hatte. Eines der Hauptprobleme bei DSSSL wurde als seine (schemaähnliche) Syntax angesehen, und es herrschte das weit verbreitete Gefühl, dass die Lösung darin bestand, dieselbe Syntax für das Stylesheet und die Daten zu verwenden. Schließlich bestand die Idee darin, dass ein Stylesheet größtenteils aus strukturierten Daten und nicht aus Programmlogik bestehen sollte und ein Großteil dieser Daten aus Proforma-Daten ("Vorlagendaten") zum Hinzufügen zum Ergebnisbaum mit einigen Parametrisierungen bestehen sollte.

XSLT wird oft als übermäßig ausführlich empfunden. Für XSLT 1.0, das leider noch von vielen Menschen verwendet wird, stimmt das wahrscheinlich, aber das Problem wurde größtenteils mit XSLT 2.0 gelöst, das oft viel prägnanter ist als andere Möglichkeiten, dasselbe Problem zu lösen.

Es gibt sicherlich Nachteile. Sie sind ziemlich verpflichtet, einen speziell entwickelten Editor zu verwenden (aber dann verwenden die meisten Programmierer syntaktisch gesteuerte Editoren für jede Sprache, nicht wahr?). Die Sprache ist nicht ganz so komponierbar wie sie sein könnte (obwohl XSLT 2.0 dies weitgehend behebt). Es gibt aber auch wesentliche Vorteile:

  1. XSLT wird häufig von Nicht-Programmierern verwendet, und für sie ist es ein großes Plus, dass sie nur eine Syntax lernen müssen, nicht zwei. Denken Sie daran, es sind all die kleinen Details wie der Umgang mit der Zeichenkodierung und dem Escapezeichen von Sonderzeichen.

  2. Die Möglichkeit, XSLT-Code mit XSLT zu verarbeiten, ist viel nützlicher, als Sie sich vorstellen können. Nahezu alle großen XSLT-Projekte nutzen diese Funktion und können sehr große Vorteile bringen. Ich habe zum Beispiel ein Online-Banking-System gesehen, dessen Benutzeroberfläche einige hundert Formulare enthielt, die jeweils von einem eigenen Stylesheet generiert wurden. Die Stylesheets wurden jedoch aus einer gemeinsamen Codebibliothek generiert, die eine hervorragende Wiederverwendung und Konsistenz des Erscheinungsbilds bietet.

  3. Es gibt einen Vorteil, den ich nicht erwartet hätte, nämlich dass die Verwendung eines eingeschränkten syntaktischen Frameworks wie XML die Sprachdesigner dazu zwingt, ein lexikalisches Konsistenzniveau beizubehalten, wenn sich die Sprache weiterentwickelt, und gleichzeitig eine große Erweiterbarkeit bietet. Die XQuery WG diskutiert immer wieder, wie die Sprache erweitert werden kann, ohne die Kompatibilität zu beeinträchtigen oder Macken einzuführen. XSLT hat keine derartigen Probleme, da es im Grunde darum geht, neue Elemente und Attribute zu definieren.


0

Ich könnte sehen, dass so etwas in einer XML-lastigen Umgebung (denken Sie an XSLT) praktisch ist, in der Sie vermutlich bereits anständige XML-Editoren haben und es nützlich sein könnte, Code mit demselben Toolset generieren zu können. Dies kann auch das Schreiben von Korrektheitsprüfern oder anderen Tools erleichtern, um sicherzustellen, dass der Code bestimmten Standards oder Regeln entspricht (z. B. definiert ein Schema, wohin die Geschäftslogik gehen muss, und / oder stellt sicher, dass alle Variablen auf konsistente Weise initialisiert werden ).


0

XSLT ist die einzige XML-Programmiersprache, die ich verwendet habe. Ich hatte keine Gelegenheit, mich mit den anderen zu befassen.

Wir haben eine Hauptanwendung, die eine XML-Datei in eine Datenbank schießt, und mehrere andere Anwendungen können diese Datei verwenden und eine XSLT-Datei darauf anwenden, um die Daten zu extrahieren, die diese anderen Anwendungen benötigen. Dadurch wird der Export eines neuen Satzes verringert Daten für jede neue Anwendung, die hinzukommt. Ich denke, das ist ein großes Plus. Sie müssen nur eine XSLT-Datei für die neue Anwendung codieren, um die bereits erstellten Informationen zu dekodieren, anstatt neue Informationen für eine neue Anwendung zu erstellen.

Mir ist klar, dass ich keine der anderen von Ihnen aufgelisteten Sprachen angesprochen habe, aber ich habe Ihnen eine Vorstellung von einem guten Ort für die Verwendung einer solchen Sprache gegeben. Ich bin mir immer noch nicht sicher, ob ich Ihre Frage vollständig oder teilweise beantwortet habe. aber hoffentlich habe ich einen Einblick gegeben.


2
Nein, in den Fragen wird gefragt, warum XSLT selbst XML sein sollte. Die von Ihnen beschriebene Toolchain hätte genauso gut mit einem Perl- oder Python-Skript implementiert werden können, das das Ausgabe-XML analysiert und daraus eine Ausgabe generiert. Die interessante Entwurfsentscheidung für XSLT ist nicht, dass es XML transformieren kann, sondern dass es keine geschweiften Klammern verwendet
amon

oder Semikolons? Ich verstehe, was du sagst. Jede Sprache könnte diese Informationen wirklich aus dem XML-Dokument analysieren. Die Frage wäre also: "Warum brauchen sie eine XML-Transformationssprache?"
Malachi

Nein, eine XML-Transformationssprache ist sinnvoll (wenn Sie viel XML-Transformation durchführen). Es gibt viele Dinge, die XSLT zur Unterstützung der XML-Verarbeitung tut (z. B. die Möglichkeit, den DOM-Baum einfach zu durchlaufen und abzufragen), aber XML selbst zu sein, gehört nicht dazu.

Ich habe versucht, die Frage mit meinem letzten Kommentar zu klären. @Delnan Ich verstehe und stimme zu, dass XSLT ein schönes Tool ist.
Malachi

-3

XML macht ohne historischen und politischen Kontext fast keinen Sinn. SGML war noch schwieriger zu schreiben, zu lesen und zu warten, aber 1986 wurde es mit dem ISO-Gütesiegel versehen, was es möglicherweise zur ersten Datendeklarationssprache machte, die eine solche Imprimatur aufwies.

Es war ausreichend nützlich und dokumentiert, um Tim Berners-Lee zu inspirieren, es Anfang der neunziger Jahre als Grundlage für HTML zu verwenden. Denken Sie daran, dass er beabsichtigte, ein World Wide Web zu erstellen, und dass es auf einem bestehenden ISO-Standard basieren würde, um dies erheblich zu fördern.

In den späten 1990er Jahren startete das World Wide Web Consortium eine Initiative für standardmäßige strukturelle Markups für den Datenaustausch, da das Web ziemlich gut verankert war. Der Hype-Faktor um XML erreichte ein beispielloses Niveau von "Wir sind uns nicht sicher, was wir damit machen sollen, aber ich wette, es wird wirklich cool".

Derzeit ist XML vor allem für den strukturierten Datenaustausch zwischen unterschiedlichen Systemen geeignet. Wie amon bemerkt hat, gibt es einige spezifische Bereiche, in denen es einen breiteren Nutzen hat. Ich bin nur froh, dass es jetzt möglich ist, Graffiti in einem standardisierten Markup zu codieren , damit Kinder in Zukunft kein Leben und keine Strafverfolgung riskieren müssen, sondern ihre Markierungen mit ferngesteuerten Drohnen mit Farbe ausführen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.