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

Volker Grabsch vog at notjusthosting.com
Fr Sep 23 21:03:16 CEST 2005


On Thu, Sep 22, 2005 at 08:11:58PM +0200, Oliver Bandel wrote:
> [...]
> > 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 :-))
> Für was steht "CDATA"?

Das hat mich nie interessiert. RTFM. ;-)

> > > 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.
> 
> Ach, ich dachte, Du propagierst es für alles mögliche.

Wo hab ich das gesagt? Ich habe stets versucht, es in den richtigen
Kontext zu setzen. Wenn du diesen ignorierst, dafür kann ich nichts.

> [...]
> > 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!
> [...]
> Deswegen ist es ja schon seit einer Weile im Gespräch füpr diese
> Anwendung, die Du mir anscheinend aufdrängen willst.
> 
> Du rennst eigentlich offene Türen ein, deswegen verstehe ich Deinen
> XML-Eifer nicht so ganz.

War wahrscheinlich ein Missverständnis.
Bei diesem Posting wolltest du immer noch unbedingt eine eigene Sprache,
und von XML als Zwischenformat hast du auch nichts geschrieben. Hättest
du das gleich gesagt, dass du das eh vorhast, hätte ich mir einige
Zeilen sparen können.

> Deswegen warte ich ja auf eine entsprechende DTD.
> Die sollten die Spezis machen. Aber viell. peilen die es ja auch nicht.

Ich denke, eine einfache DTD für deinen Zweck ist besser als gar nicht.
Vorallem sehr viel besser, als wenn du das "Enduser"-Format direkt in
das Druckformat umwandelst.

> > Dieses Format sollte sich als Standard etablieren, und
> > zentraler Ausgangspunkt für alle Labannotation-Programme sein,
> 
> Ich fragte auch nach Standardisierung der Notation.
> Es gab Diskussionen - und keine Ergebnisse.
> 
> Immerhin gibt es auch noch unterschiedliche Notationsformen in USA und Europa.

Wenigstens nur zwei. ;-)

> [...]
> > Ich nenne es einfach mal LabanXML, oder gibt's dafür schon nen Namen
> > und ne Dateiendung?
> [...]
> 
> bleib ma locker. ;-)

Können die sich überhaupt auf was einigen? Arbeitet überhaupt jemand
an der DTD?

> > Nur zum händischen Bearbeiten, da sollte noch was anderes her.
> Ach ne?! ;-)
> Sach ick doch die ganze Zeit, daß XML zu wilde Tipperei ist.

Ja richtig, und ich habe dir zugestimmt. Und das hast du nicht "die
ganze Zeit" gesagt, sondern genau in einer Mail, bei der ich dir in
meiner Antwort zugestimmt habe.

> [...]
> > Überschrift1
> > ------------
> > 
> > Hier kommt ne Aufzählung
> > - Bla
> > - Bli
> > - Blubb
> > 
> > 
> > ... die meisten README-Dateien sind deshalb schon ReST.  ;-)
> 
> ReST in peace? ;-)

ReStructured Text.

Die einzige Wiki-Sprache, hinter der ein ordentliches Kommandozeilen-
Konvertierungssystem steckt. Die anderen sind ziemlich ans Web genagelt.

Deshalb sind ReST und Docutils ja so ziemlich das einzige, was meinem
Wikidok-Vorhaben wirklich entgegen kommt.

> > Man hat Symbole, eine
> > Satzbild, Zeilenumbrüche, gewisse Einheiten, die man die trennen darf,
> > Symbole, die nebeneinander, aufeinander etc. angeordnet sind.
> 
> TeX/LaTeX haben keine native Grafiksprache.
> Deswegen sind die beiden dafür nicht wirklich gut geeignet.

Achso? Vielleicht nicht zum Malen der Laban-Symbole, wohl aber zum
Anordnen, oder? (siehe obige Frage, ob mit Laban-Font nicht auch LaTeX
vollkommen reicht)

> > Ja,
> > wiegesagt, vom Konzept her sind Musiknoten immer noch Textsatz,
> Nein.
> Es gibt Ähnlichkeiten, mehr nicht.

Es gibt verdammt viele Ähnlichkeiten, insbesondere sind AFAIK die
Anordnungs-Algorithmen (Absatz-Modus) die gleichen. Es ist lediglich
andere Grundsymbole, halt keine Buchstaben, sondern Noten. Auf die
einzelnen Noten bezogen, wenn man sie gruppiert, kommen wiederum ein
Haufen Parallelen aus dem Formelsatz (Mathematik-Modus), ...

> > und
> > deshalb gibt's das ja auch als TeX-Erweiterung, MusiTeX.
> 
> MusicTeX meinst Du?
> Es gibt, weil das so grob zu bedienen ist, dafür auch Preprozessoren.

Ja, das ist die Tragödie. Aber ich vermute, das hat auch grundsätzliche
Ursachen: Noten per Markup-Sprache zu tippen ist einfach zu mühselig.

Ansonsten ist MusicTeX wirklich leider eher ein Gegenbeispiel für das,
was TeX alles erledigen kann. Ich weiß aber nicht, ob das ein
Fehl-Design von MusicTeX ist, dass die es zu kompliziert gemacht haben,
oder ob das eher grundsätzlicher Natur ist, dass man mit Maus-Hilfe
einfach mal schneller ist. Von einem Midi-Interface + Keyboard mal ganz
zu schweigen. ;-)

> Naja, aber es gibt sehr viele programme für Musiksatz mittlerweile.
> Rosegarden soll ganz gut sein, und noch ein/zwei weitere.

Rosegarden hab ich mal viel verwendet. Und es exportiert MusicTeX :-)

> > Und Labannotation ist es, wenn man Analysetools außen vor lässt,
> > ebenfalls.
> Nein.
> Es ist Grafiksatz. Mit Textsatz kommst Du da nicht mehr weiter.

Von mir aus. Das habe ich wiegesagt dazu gezählt.

> Geht nur bei so sequentiellen Sachen wie den Skalen,
> die der Laban-Scale-Generator erzeugt.

Zeig mal bitte was her, wo LaTeX dir nicht mehr helfen kann.


Viele Grüße,

	Volker

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



Mehr Informationen über die Mailingliste linux-l