[linux-l] Sprache für Laban-Choreographien (was: Grammar Design)

[Volker Grabsch]

On Tue, Sep 20, 2005 at 01:24:13AM +0200, Oliver Bandel wrote:
> Jedenfalls ist das, was ich da machte, ein Subset der Symbole und auch nur in einer
> Anwendung, die in diesem Falle einfach nur das setzen der Symbole in einer Reihe
> erfordert.

Okay, dann wiegesagt Aufgabentrennung: Kümmere dich nicht mehr um
Überschriften etc. in deiner Sprache, auch nicht in der DTD, sondern
nur um die Laban-Diagramme. Wenn es erstmal nur einzelne Symbole sind,
die nebeneinander stehen, ist das okay. Sie dann in entsprechend andere
Formen zu gießen bzw. kleine Makros für wiederholende Muster, das wäre
dann der nächste Schritt.

Um Überschriften, Texte etc. würde ich mich absolut nicht kümmern.
Generiere PNG, dann können sie es in Word dazu schreiben, oder
generieren LaTeX, dann kann man es direkt dort dazuschreiben.
Aufgabentrennung halt.

> Da es für so etwas aber auch noch keine Software gibt, war das für die Leute aus der
> Laban-Ecke sicherlich ein erster Knaller... :)

Hui, so schnell? Die Branche ist damit, IT-mäßig gesehen, offenbar
wirklich noch unterentwickelt. Ein Grund mehr, aufzupassen, dass sie
sich nicht verrennen! In der Branche fehlen die Informatiker und
wohl noch dringender Mathematiker, kann das sein?

> Meine Mails auf den entsprechenden Listen, man solle doch mal einen Font entwickeln
> verhallten ohne Ergebnisse.

Fang einen an, warte auf Feedback. ;-)
Jaja, ich weiß, es gibt Leute, die dafür bezahlt werden ... bzw. bezahlt
werden sollten.

> Immerhin war der Entwickler vom LabanWriter so nett, seine Symbole als TTF
> zu exportieren. aber die Symbole haben woghl nur Bildschirmauflösung, was
> das ganze nur bedingt einsetzbar macht.

Wie regelt er die Symbole intern? Ist Labanwriter wenigstens quelloffen?
Davon abgesehen kann es doch nicht soo schwer sein, wenn du das sogar
fast per Hand in PostScript als Font hingekriegt hast.

> > Das 1) Problem hast du weitestgehend gelöst mit einem IMHO sehr
> > geeigneten Ansatz.
> 
> Ich habe das problem gelöst für die horizontale Notation.
> Man kann die Skalen auch vertikal schreiben.

Toll. Dann erzeuge die Symbole einzeln und nimm LaTeX oder SVG,
wiegesagt.

> Aber Postscript sieht dies ja glücklicherweise als Möglichkeit
> for. Neben "sho" gibt es auch "ashow" und "kshow" und so.
> Einer von diesen Operatoren kann auch senkrecht setzen,
> so, wie man es z.B. auch für japanische Schriftzeichen braucht.

LaTeX müsste das auch können (hab's nicht ausprobiert), SVG kann's
auf jeden Fall.

> > Eine "neue Sprache", also die Buchstabenküzel,
> > ist IMHO gerechtfertigt und eine gute Idee.
> 
> IMHO aus Programmierersicht naheliegend, beziehe mich aber dennoch auf
> Kürzel, die in der Literatur benutzt werden (wie gesagt aber nicht einheitlich).

Naja, aber im Wesentlichen ist doch jedes Symbol lediglich durch gewisse
Parameter, die man auflisten kann, eindeutig bestimmt, oder?

> > Vorallem, weil es offenbar
> > noch keine standardisierte "eintippbare" Beschreibung dieser Symbole
> > gibt.
> Bisher tippen die Leute nicht ihre Skalen als Texte, sondern klicken herum.

Auch nicht so tragisch, wenn's wenigstens ein einheitliches internes
Format gäbe.

> > Das 2) Problem hingegen ist, nüchtern betrachtet, einfach bloß Textsatz.
> 
> Nein, nur wenn man die horizontale Schreibweise der einfachen Notation
> der Richtunbgssymbole für die Skalen nimmt.

Tabellarische Anordnung, oder vertikale, oder Drehungen um 63,78 Grad,
das ist alles Textsatz!

Angenommen, diese Laban-Symbole wäre bloß Buchstaben. Würde sich dann
das gesamte Zeug nicht fast komplett mit LaTeX erschlagen lassen?
Vielleicht ein paar Makros zur Vereinfachung von irgendwelchen tabular-
Umgebungen oder so, aber im Wesentlichen lässt sich das doch alles damit
erschlagen, oder?

> Man kann Word-Nutzer, die sich für Computer-NICHT-Kenner halten, teils
> schon weit über 60 sind,  nicht so einfach davon überzeugen, daß sie ihre
> Texte zukünftig nicht tippen, sondern programmieren sollen.
> 
> Du vergißt diese psychologische Hemmschwelle.
> 
> Den Leuten darf man nicht sagen, daß sie programmieren, selbst wenn sie es tun.
> Erst, wenn sie es bereits erfolgreich getan haben kann man sagen, daß sie aber
> ganz schön eifrige Programmierer sind. ;-)

Wiegesagt, das ist IMHO nonsens, denn 1. programmieren sie nicht, sie
verweden nur eine Dokumentensprache, und 2. geht es darum, was du tust
(Text tippen statt rumklicken), und nicht darum, wie du's nennst.

> > [DTD für Laban]
> > > Mit irgendwas muß man aber anfangen, und da ich keine vorhandene
> > > DTD habe, und da diese auch von den Labannotations-Spezis entwickelt
> > > werden sollte, nützt mir auch ein XML-Parser erst mal nix,
> > 
> > Ich verstehe leider immer noch nicht, wozu dieses XML-Format gut sein
> > soll.
> 
> Ich dachte, DU bist der XML-Apologet. ;-)

Nein, bin ich nicht. Ich habe sehr, sehr viel Missbrauch von XML schon
gesehen, sodass ich sehr vorsichtig geworden bin. Aber je mehr du von
Labanotation erzählt hast, umso mehr bin ich zu der Überzeugung gelangt,
dass ihr von XML ordentlich profitieren würdet. Übrigens musst du nicht
für jedes Laban-Symbol ein extra XML-Tag verwenden, wenn das nicht nötig
ist. Eine Variante wäre z.B.

<?xml version="1.0"?>
<labanotation>
  <line>EFR HT W TE ZRW</line>
  <line>RE Z UZ R RE</line>
</labanotation>

Das ist immer noch leicht zu parsen. Aber wenn die Symbole irgendwie
mehr Informationen brauchen, dann musst du eben weiter gehen:

<?xml version="1.0"?>
<labanotation>
  <line>
    <symbol what="leg" from="left" to="right"/>
    <symbol what="arm" from="left" to="right"/>
  </line>
</labanotation>

Naja, musst du selbst sehen, was sinnvoll ist. Nur ein paar Anregungen
zum grundsätzlichen Umgang mit diesem Problem. Beide Ansätze haben Vor-
und Nachteile. Der Vorteil der zweiten Version ist aber, dass es sehr
viel dichter an der Semantik ist, und das ist doch der Zweck des
"LabanXML"-Formats, richtig?

> BTW: Wenn man einen Laban-Score hat, hat man u.U. neben der von unten nach
> oben laufenden Bewegungsnotation noch Extra-bereiche auf dem Blatt,
> wo die Floor-Plans drauf sind.

Das würde ich dem Textsatz-System überlassen und nicht ins LabanXML mit
integrieren. Die Herausforderung in diesen Fall ist es glaubich, die
Trennung möglichst sinnvoll zu finden, und dieses LabanXML-Format eben
*nicht* mit Textsatz zu überfrachten.

> Man kann das dann auch noch ergänzen um
> Musik-Noten, die man entweder irgendwo noch auf dem Papier unter bringt, oder
> die man grafisch synchron zu der Bewegung notiert, wobei dann natürlich die
> Musik-Noten um 90 Grad gegen den Uhrzeigersinn rotert werden und dann
> zeitlich mit dem Bewegungs-score übereinstimmen müssen.

Spätestens hier sollte wirklich Schluss sein. Da gehört da einfach nicht
rein. Vielleicht im Laban-XML Verweis auf ein externes Musik-Dokument,
aber mehr nicht.

> So, und da wäre also der Unterabschnitt der Erstellung von Musiknoten-Satz.
> Der ist für sich allein übrigens auch nicht trivial, und wäre da nur ein Subsystem,
> das in den Laban-Score mit rein müsste.

Nein, der sollte nicht mit rein. Ich kenn mich zu wenig damit aus, aber
ich denke, da ist wieder eine Grenze, die man ziehen sollte. Genauso,
wie man IMHO auch keine Überschriften etc. mit reinbringen sollte.

Sicher ist es Sinnvoll, sowas später zusammenzubringen, aber nicht durch
ein Monster-Format, sondern durch intelligentes Zusammenspiel. Man
sollte sich bei der DTD erstmal nur um die Laban-Symbole und ihren Satz
in Form von Tabellen o.Ä. kümmern.

Die Noten kommen doch eh aus einer anderen Datei, und da sollten sie
auch bleiben.

> Es wäre natürlich gut, wenn auch weitere, nicht nur die Richtungssymbole,
> in ein Textsystem integriert werden könnten.
> Die Antriebs-Symbole (Effort-Graph) hatte ich mal mit pstricks in LaTeX
> eingebunden. War nicht perfekt, aber die Ergebnisse waren ganz brauchbar.
> Aber sowas dann zu tippen im Dokument... da krigt man auch fast 'ne macke!

Sieh es ein: Manchmal ist die Maus der schnellere Weg.


> > Aber falls es wirklich nötig wird, löst deine eigene Syntax doch
> > keine Probleme, die XML nicht ebenfalls lösen würde.
> 
> Naja, wenn man auch Funktionen integrieren kann, dann geht auch XML.
> Ich dachte vorher, das wäre nicht XML-konform und hatte was XML-ähnliches
> selber entwickelt, und dann Funktionen-Funktionalität dazu implementiert.
> Daß man aber auch sowas mit XML bauen kann, meintest Du ja, würde gehen.
> Also kann XML doch in Frage kommen.
> (ein bischen was wie re-inventing XML wäre es sozusagen geworden ;-))

Nein, XML kennt keine "Funktionen". Es kennt nur Tags (Elemente),
Attribute und Text. Und noch ein bisschen Kleinkram mehr (Kommentare,
Processing Instructions), das war's. Ob du die Elemente als
Laban-Symbole, Zeilen, Absätze, Funktionen oder sonstwas auffasst,
das ist XML schnuppe. Diese inhaltliche Interpretation hat dein
Programm zu machen.

Von daher ist die Frage, ob in XML Funktionen erlaubt sind, genauso
sinnvoll wie die Frage, ob man in HTML auch Nazi-Propaganda schreiben
kann, oder ob die LaTeX-Syntax eingentlich Rechtschreibfehler erlaubt.
;-)

> Ich will auch nicht derjenige Sein, der (auch noch unbezahlt)
> die Irrwege geht, aus deren Fehlern die anderen Leute, die auch noch
> dafür bezahlt werden, lernen, um dann ihre Merits abzugreifen.
> Hinterher kann ich dann noch froh sein, wenn ich die Software benutzen darf?
> 
> Nö.
> Dann sollen die Spezis das mal machen.

Du kannst einen kleinen, guten Anfang machen, um sicherzustellen, dass
es später nicht nur PDF- und Flash-Output gibt, und dass die Software
auch ohne GUI funktioniert, und dass sie nicht nur unter Windows läuft.
Diese technischen Ansprüche kannst du nämlich schonmal setzen, wenn
du das implementierst.

Dennoch schreit meine "Mathematiker-Seele" auf, und ich komme immer noch
nicht von dem Eindruck los, dass die ganze Sache gar nicht so schwer
ist, wenn sich nur jemand mal die Mühe machen würde, das sauber zu
abstrahieren, und in unabhängige Teilaufgaben / Schichten zu zerlegen.

Ich vermute (korrigiere mich gern), dass es gar nicht das Problem ist,
eine abstrakte Form für diese Dinge zu finden, und ich glaube auch
nicht, dass diese Abstraktion am Ende wirklich kompliziert sein wird.
Ich glaube einfach nur, dass diejenigen, die ein intuitives Verständnis
davon haben, nicht in der Lage sind, das ganze in einer abstrakten
Sprache zu formulieren. Ich befürchte, genau solche Leute fehlen euch,
und man nennt sie Mathematiker.
(Manche nennen sie auch Informatiker, Ingenieure oder Designer, aber die
eben angesprochenen Fähigkeiten liegen im Bereich der Mathematik, und
das schließt sich ja nicht gegenseitig aus, im Gegenteil.  Bei uns an
der Uni schreiben wir Mathe-Studenten, die Info als Nebenfach haben,
dort die besten Noten, warum wohl?)


Aber man darf Leuten nicht sagen, dass sie da eigentlich Mathematik
betreiben, sonst sind sie abgeschreckt. ;-)  Stattdessen haben sie
ihren "Programmcode aufgeräumt", eine "Datenstruktur designt", etc.
alles Kram, für den man keine Programmierer-Skills braucht und auch
nicht sonstwieviele Programmiersprachen können muss (obwohl das
natürlich von Vortei ist). In großen Projekten, gutes Teamwork bei
allen Teilnehmern vorausgesetzt, unterscheiden sich die guten
Programmierer von den schlechten vorallem durch ihre *mathematischen*
Fähigkeiten. Genau das selbe in der Planung und im Management.
Mathematische Fähigkeiten (damit meine ich nicht Kopfrechnen, sondern
Abstraktionsvermögen) sind es, die einen da weiterhelfen, IMHO, obwohl
das nur wenigsten so nennen.


Viele Grüße,

	Volker

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