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

[Oliver Bandel]

Moin Volker,


On Thu, Sep 22, 2005 at 02:14:54PM +0200, Volker Grabsch wrote:
> 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).
[...]
> 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"?


> 
> 
> > 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.

[...]
> 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.

[...]
> 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.

Aha, Na, das ist mir aber nix neues.
Deswegen warte ich ja auf eine entsprechende DTD.
Die sollten die Spezis machen. Aber viell. peilen die es ja auch nicht.


> 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.


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

bleib ma locker. ;-)


> 
> 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.


[...]
> [ 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.
[...]

> 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.

Naja, viell. ist deswegen dieses krasse Tool, das ich meinte,
auch in Python geschrieben worden.

 
[...]
> 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)

In Haskell kann man sich entscheiden, ob man Code mit eingetreuten
Kommentaren nutzen will, oder text mit eingestreutem Code.
Eine simple, aber recht wirksame Methode! :)

In Perl gibt es POD.

Bei Ocaml habe ich mich darum noch nicht gekümmert, aber da gibt es
einmal wohl ocamlbrowser zum schnellen suchen in Libs/Code (in der Distri)
und dann auch LP-Tools (nicht in der Distri).

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

ReST in peace? ;-)


[...]
> > 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.

Nur ähnlich, mehr nicht.
Vieles auch ist verschieden.

> 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.


> Ja,
> wiegesagt, vom Konzept her sind Musiknoten immer noch Textsatz,

Nein.

Es gibt Ähnlichkeiten, mehr nicht.

> 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.

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


> 
> 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.

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


> 
> > 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.

Ergebnis: Ja, würden wir gerne machen, aber es fehlt an Finanzmitteln.

Wenn ich dann sage: Würde ja gerne dies und jenes entwickeln, aber es fehlen
Finanzmittel, heisst es: die Arbeit solle im Vordergrund stehen und über
Geld zu lamentieren mache keinen Sinn...


Alles klar.

So, wie es so oft im OpenSource-bereich abgeht: Die Leute mit Job
machen nebenbei OSS und verlangen on denen ohne Job, gefälligst
auch OSS für kostenlos anzubieten. Sponsoring? Ach nööööö.... :(

Ciao,
   Oliver