[linux-l] Vor- und Nachteile von XML (was: Grammar Design)

Do Sep 22 14:14:54 CEST 2005

Hallo Oliver!

Hier erstmal ein paar allgemeine Bemerkungen zu XML.
Konkret zu Labannotation komme ich in einer weiteren Mail, weil
das mit dem hier eher wenig zu tun hat.

On Mon, Sep 19, 2005 at 09:51:39PM +0200, Oliver Bandel wrote:
> > Beispiel 2:
> > -----------
> > 
> > <meindokument>
> >   <script language="C">
> > 
> >      if (1<2) {
> >        printf("Hello World!\n");
> >      }
> > 
> >   </script>
> > </meindokument>
[...]
> Oha. Coole Idee. :)

Ist keine "Idee" von mir, sondern Stand der Technik. Wie wird denn z.B.
JavaScript in XHTML eingebettet? Auch in SVG (einer XML-Sprache) kann
eine Scriptsprache eingebunden werden (z.B. JavaScript oder ECMAScript).

> nur doof ist es, wenn man sowas von hand tippen muß.
> Ein Nutzer, der das von hand editiert würde sich darüber aufregen,
> daß man die Programmiersprache C in diesem Falle nicht 1:1 eingeben kann, wie man
> es will.
> Mal eben einen C-File hier einfügen geht nicht.
> man muß dann erst den C-Code konverteirern.
> Das ist dann wieder Anwender-Unfreundlich.

Du meinst das Problem beim Quoting. Ja, das existiert, aber die Vorteile
überwiegen dennoch. Die äußere Sprache muss nur in der Lage sein, einem
die Quoting-Orgien zu ersparen, da hast du recht. Das können aber die
meisten Sprachen. Zum Beispiel Python hat seinen Tripplequote-Strings
(""" ... """), sodass einzelne " und ' innendrin nicht mehr gequotet
werden müssen. Und XML hat auch sowas, das nennt sich CDATA:

<meindokument>
  <script language="C">

    <![CDATA[

     if (1<2) {
       printf("Hello World!\n");
     }

    ]]>

  </script>
</meindokument>

Noch ein Grund, schon *fertige* XML-Parser zu nehmen. Da muss man sich
um <![CDATA[...]]> nämlich genau gar nicht kümmern, es könnte genausogut
gar nicht vorhanden sein, und stattdessen das "<" entsprechend gequotet.
Kein Unterschied. (außer vielleicht ein paar Newlines :-))

> Naja, für manche einfache Sachen ist mir XML einfach zu viel Tipperei.

Ja, das ist wahr. Als Import- und Export-Format, und vielleicht noch als
internens Speicher-Format, ist XML hervorragend geeignet, da kann man
von allen Features, Standard und Technologien, die dahinter stecken,
wirklich profitieren. Hauptsache, der XML-Kram wird vorrangig vom Computer
verarbeitet. Wenn ich XML möglichst wenig anfassen muss, dann geht's.

Aber XML wird meistens für weitere Sachen missbraucht:
Konfigurations-Dateien, Markup/Dokumenten-Sprachen, ...
also Sachen, wo man nicht nur kurz was anpasst, oder die man automatisch
generiert. Nein, diese Dinger muss man irgendwann im Editor
zusammentippen, und das ist lästig!

> > Die Frage ist, was dein Programm aus diesem XML-Code
> > macht. XML an sich legt nur die Grammatik fest, nicht die Struktur!
> 
> OK, ok.
> 
> Aber ist auch viel Tipperei.
> Immer den Tag zum Öffnen der Umgebung und einen zum
> Schliessen der Umgebung.
> 
> Da sind TeX's geschweifte Klammern wesentlich bequemer. :)
> Man muß halt weniger tippen.
> 
> {\bf bold face}
> 
> statt wie z.B. in HTML
> 
> <b> bold face </b>

Meine Rede! Full ACK.

Auch bei Konfigurationsdateien würde ich von XML abraten.
Nehmen wir z.B. das hier:
-------------------------------------------------------------------
<?xml version="1.0"?>
<config>
  <main>
    <size>150</size>
    <version>1.4</version>
  </main>
  <tester>
    <debug>4</debug>
  </tester>
</config>

In jeder anderen Sprache brauche ich keinen XML-Header und kein
alles umspannendes Tag (config). Nehmen wir YaML:
-------------------------------------------------------------------
main:
  size: 150
  version: 1.4

tester:
  debug: 4

Oder S-Expressions:
-------------------------------------------------------------------
(main
      (size 150)
      (version 1.4))
(tester
      (debug 4))

Oder Ini-Dateien:
-------------------------------------------------------------------
[main]
size = 150
version = 1.4

[tester]
debug = 4

JSON gibt's auch noch, das lass ich aber mal außen vor.

Wenn man (wie bei Configfiles) die Vorteile von XML nicht braucht,
sollte man sich auch nicht die Nachteile (Editorfeindlichkeit)
einhandeln. Im konkreten Fall von Konfigurations-Dateien bin ich
i.A. für Ini-Dateien, die reichen meist völlig aus und sind ein
weit verbreiteter Standard. Wenn sie nicht reichen, fährt man
mit JSON, YAML oder S-Expr immer noch besser als mit XML, aber
mit XML fährt man immer noch besser als mit einer selbstgehackten
Sprache, IMHO.

> > Nein, ich meine, du brauchst keine extra neue Sprache.
> 
> ja, I see.
> 
> Bzw. Du meinst, ich brauche schon eine neue Sprache, aber
> nutze dafür XML als Grundlage.

Nicht unbedingt XML, vielleicht eher TeX oder LOUT als syntaktische
Grundlage. Für deine Zwecke könnten auch S-Expressions gute Dienste
leisten. Vielleicht schaust du dich mal um, da gibt es eventuell
sogar noch besser geeignete Sachen.

Aber wohlbemerkt, zum Editieren! Als internes Format für semantische
Analysen, für Import/Export aus Labannotation-Editoren, etc., dafür
ist XML wieder sehr gut geeignet, und zwar sehr viel besser als alles
andere!

Du solltest IMHO daher wirklich mit einer DTD bzw. einem XML-Schema
anfangen, das ist auch für dich Persönlich gut, weil du dich dabei
mehr auf die Struktur konzentrierst, und nicht mehr so viel auf die
Grammatik der Sprache (die ja XML schon vorgibt).

Ein solches Format wäre wirklich praktisch für alle Sorten von
automatischer Bearbeitung, Generierung, etc.

Nur für eines leider nicht, nämlich für das manuelle Editieren.
Okay, wenigstens geht es überhaupt, und kleinere Änderungen sind
ja gar kein Ding, aber für das Schreiben von Labannotation mittels
Texteditor, da ist XML eine sehr ungeeignete Sprache, nicht nur für
Anfänger.

An dieser Stelle müsste was anderes her, und von der Syntax empfehlen
sich TeX oder S-Expressions als Grundlage.

> Es gibt einige wenige voin denen, die haben auch was eigenes implementiert.
> Es gibt auch ein programm LabanWriter. Aber das ist letztlich bloß ein
> Zeichenprogramm mit speziellen Symbolen.
> Deswegen finde ich, muß eine Beschreibungssprache her, die für Laban-Scores nutzbar
> ist. Diese gibt es aber noch nicht, und das wollte ich eigentlich den Spezis
> überlassen (oder selber machen, wenn ich mal de Notator-Ausbildung machen würde;
> müsste ich aber erst mal finanzieren können).

Okay, jetzt habe ich wohl genug verstanden, um eine durchdachte
Design-Empfehlung zu geben:

Die Beschreibungssprache sollte wirklich XML sein, und zwar *kein*
selbstgestricktes, vereinfachtes XML-ähnliches Format, sondern
gültiges, strenges XML mit DTD bzw. Schema, das von allen XML-Parsern
verstanden wird. Dieses Format sollte sich als Standard etablieren, und
zentraler Ausgangspunkt für alle Labannotation-Programme sein, egal ob
es um PDF-Generierung, semantische Auswertung oder WYSIWYG-Editoren
geht. XML bietet nämlich sehr viel Stabilität, sodass dieses
Dateiformat über lange Zeit brauchbar und verlässlich sein wird.
Und die ganzen Tools, Standards, Namespaches, und was es alles gibt,
werden dabei unschätzbare Dienste leisten, auf die ihr keinesfalls
verzichten solltet.

Ich nenne es einfach mal LabanXML, oder gibt's dafür schon nen Namen
und ne Dateiendung?

Nur zum händischen Bearbeiten, da sollte noch was anderes her. Nach
der Unix-Philosophie wäre ein Textformat geeignet, aus dem ein Tool
dann LabanXML erzeugen kann. Auch die Rückkonvertierung (eventuell
verlustbehaftet) sollte später möglich sein. Und diese Sprache sollte
entweder schon existieren (LaTeX), die Teilmenge einer existierenden
Sprache sein (LaTeX ohne \documentclass - Schmus), oder was am besten
wär: es sollte der Spezialfall eine Universalsprache sein, für die es
bereits Parser etc. gibt, z.B. S-Expressions. Schau z.B. mal im GNU-
Projekt unter GUILE, an sowas dachte ich gerade. Schau dich einfach
mal um. Mindestens
	XML, YaML, S-Expressions (oder Guile), ConTeXt und Lout
solltest du wenigstens mal gesehen haben, und dich jeweils 10min
damit beschäftigt haben.

Aber *erstmal* reicht LabanXML, das solltest für Analyse und für
PDF-Generierung die Ausgangsbasis darstellen. Ich empfehle folgenden
"Schlachtplan":

1. LabanXML definieren (nicht zu viel, muss nur alles drin haben,
                        was du erstmal machen willst)

2. LabanXML -> EPS oder SVG implementieren, ab besten per SAX-Parser,
   schau dir "libxml2" an. Wird nun sehr einfach und schnell von
   der Hand gehen.

3. Webinterface dadrum schreiben, im Eingabefeld gibst du LabanXML
   vor. Nicht schön, aber es reicht zum Spielen und um ein paar
   Sachen im XML-File zu ändern und zu schauen, was dann passiert.

4. editorfreundliche Sprache wählen (ich nenne es mal LabanTeX),
   und einen Konverter LabanTeX -> LabanXML schreiben.

5. Dann 2. und 4. via Webinterface verbinden.

6. LabanXML um weitere Sachen erweitern, die dir mittlerweile in
   den Sinn kommen, eventuell schon in 2. implementieren.

7. Deine DTD bei den Laban-Leuten zur Diskussion stellen.

8. LabanTeX entsprechend erweitern. (d.h. in 4. implementieren)

9. (erst jetzt!) Analyse-Tool beginnen, basierend auf LabanXML

[ Literate Programming ]
> > Das ist was anderes. Hast du dir die bisherigen Werkzeuge alle
> > angesehen?
> 
> Nicht alle, aber einige.
> Es soll übrigens eines geben (habe ich noch nicht angeschaut), das
> schon richtig krass ist und auch Definieren von Funktionen erlaubt
> und krass verschachtelte Syntaxes... und das teil ist wohl sogar in Python
> geschrieben.

Also erstmal gibt es für Java das JavaDoc und in Python nativ eingebaut
die Docstring, sodass du dir sogar im laufenden Programm die
Dokumentation (per reflection) holen kannst. Beispiel:

def inc(x):
    """Liefert einen größeren Wert als x zurück."""
    return x+1

print inc(1)
>>> 2

print inc.__doc__
>>> Liefert einen größeren Wert als x zurück.

Das ist natürlich nur die Spitze des Eisberges. Es ging mir hier aber
nur um das Prinzip: Python als hochdynamische Sprache erreicht eine
sehr viel bessere Vereinigung von Code und Dokumentation, als es die
meisten "Literate Programming" Tools jemals könnten. So einen
Dokumentations-String der inc-Funktion nennt man Docstring.

Mittlerweile gibt es in Python auch eine ganz besondere Art von
Unittest: Docstring-Tests (oder so ähnlich heißt das). Wenn du in deinem
Docstring nämlich Beispiel-Code drin hast, zur besseren Erklärung, kann
dieser Beispiel-Code sogar automatisch überprüft werden:

def inc(x):

    """Liefere einen größeren Wert als x zurück.

    Beispiel:
    >>> inc(1)
    2
    >>> inc(99)
    100
    >>> inc(-60)
    -59

    Die Bedingung inc(x) > x ist stets erfüllt:
    >>> import random
    >>> x = random.random()
    >>> inc(x) > x
    True
    """

    return x+1

Da kannst du ein Tool rüberjagen, das alles Docstring aus allen Modulen
deines Pakets herausnimmt, die Beispiel-Codes herausfiltert (die werden
durch >>> markiert, weil das im Python-Interpreter immer so aussieht),
und sie allesamt ausführt und die Ergebnisse mit den Vorgaben vergleicht.

Literate Programming gehört also zu den vielen Sachen, die in Python
schon "all inclusive" sind, und zwar ohne großartige syntaktische
Spielereien. (syntaktisch gesehen ist ein Docstring bloß ein String, der
als erster Befehl in ner Funktion oder Klasse auftaucht)

Nur mal so zu dem Thema. Bei anderen Sprachen, die darauf nicht
eingestellt sind, sollte man den Parser eben dieser Sprache hernehmen,
alle Kommentare rausfischen, und innerhalb der Kommentare sich auf
ein Format einigen. Bei Python ist das reiner Text, bzw. wenn, dann
nimmt man ReST (restructured Text, sieht aus wie normale Textdateien,
also README-Dateien und so). Bei anderen Programmier-Sprachen nimmt
man TeX. für die Dokumentations-String, bei Java z.B. gibt es eine
HTML-ähnliche Syntax.

Aber eigentlich braucht man keine völlig neue Sprache dafür, und
auch keinen eigenen Parser. Man muss nur eine geeignete Syntax für
Dokumentations-Schnipsel finden. Mit TeX, HTML oder ReST fährt man
da schon recht gut. Dass in Java so ein Eigenbau-HTML genommen wurde,
halte ich für bedenklich und eine sehr ungünstige Wahl. ReST hat im
Gegensatz zu TeX und HTML übrigens den Vorteil, dass man es auch ohne
Transformation gut lesen kann:

Überschrift1
------------

Hier kommt ne Aufzählung
- Bla
- Bli
- Blubb

... die meisten README-Dateien sind deshalb schon ReST.  ;-)

> Naja, eigentlich wird es bisher nicht hauptsächlich zum Erstellen von
> Choreographien genutzt, sondern meist in einem archivarischen Herangehen.
> Choreografien werden meistens zusammen mit den Tänzern/Tänzerinnen
> in einem gemeinsamen Arbeitsprozess erstellt.
> 
> Mangels vorhandener Datenstrukturen ist es auch noch nicht möglich,
> Choreografien mit Computerhilfe zu analysieren.
> Die DTD läßt noch auf sich warten, obwohl immer wieder das Thema
> mal angeschnitten wird, hat sich anscheinend bis jetzt noch nichts
> brauchbares getan. Die Leute, die damit arbeiten nutzen also ihren Computer
> bisher in einer Art und Weise, wie die Leute auch mit Word i.A. ihre texte schreiben.

Dann würde ein, wenn auch nur sehr pragmatischer, Ansatz für eine DTD
da bestimmt Schwung reinbringen.

> Immerhin gibt es wohl mittlerweile eine DTD für Musiknoten.
> Aber eben noch n icht für Bewegungsnotation.

Für Musik gibt's übrigens auch MusiTeX, und überhaupt ist Notensatz dem
Textsatz in vielerlei Hinsicht verdammt ähnlich. Man hat Symbole, eine
Satzbild, Zeilenumbrüche, gewisse Einheiten, die man die trennen darf,
Symbole, die nebeneinander, aufeinander etc. angeordnet sind. Ja,
wiegesagt, vom Konzept her sind Musiknoten immer noch Textsatz, und
deshalb gibt's das ja auch als TeX-Erweiterung, MusiTeX.

Und Labannotation ist es, wenn man Analysetools außen vor lässt,
ebenfalls.

> habe aber nochmal in der entsprechenden Mailingliste nachgefragt, ob sich
> da mittlerweile was getan hat.
> Ich denke aber mal, nicht.

Würde mich mal interessieren, wenn du mehr darüber erfährst.

Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR