XML?

[fjh]

Hallo Thomas und die anderen,

*hüstel* Cocoon2 und Tomcat 4+ tun dies bereits. So ganz gefällt mir das nicht, da in diesen XML-Dateien schon mehr oder weniger programmiert wird.

Das "programmieren" müsste man aber in Anführungszeichen setzen. Bei Tomcat sowieso nicht, da ist es reine Konfiguration/Administration. Bei Cocoon gebe ich Dir (mit den Anführungszeichen) recht. Es ist eben der für Frameworks oft typische Versuch, möglichst viel von der Komplexität der reinen Programmierung und des Zugriffs über APIs aus Programmen in eine "von aussen" konfigurierbare, *beschreibende" Datei zu packen. Dort wird beschrieben WAS zu tun ist, aber nicht (oder möglichst wenig) WIE. Cocoon2 ist allerdings ein gutes Bsp. dafür, dass dann auch diese Form (die man z.B. deskriptive oder auch administrative Programmierung) schnell ihre eigene Komplexität entwickeln kann. Wenn man z.B. in den Sitemaps von Cocoon auf die Reifenfolge achten muss, wo welche "Anweisung" steht u.ä.
Das die Beschreibung für ein XML-Framework in XML erfolgt, ist allerdings konsequent und zeigt, dass das Projekt "der eigenen Sache traut".

Richtig, und man sollte auch mal bedenken, dass man mit XML nicht nur Textdaten beschreiben kann, sondern Strukturen beliebiger Art, egal ob Musikstuecke, Vektorgrafik, technische Daten ... es gibt keine Grenzen.

Hm, mit vielen Modelierungstechniken kann man dass. Es ist immer nur die Frage, ob eine Technik für bestimmte Dinge geeigneter ist als eine andere. XML ist dabei für erstaunlich viel geeignet, für manche Strukturen aber auch weniger, wenn man an stark relational verknüpfte Daten denkt.

Insofern hinkt sowohl der Vergleich mit anderen Bemuehungen, strukturierte Dokumente zu beschreiben, als auch mit Vergleichen zu Datenbanksystemen.

OK, schon klar was gemeint ist. Der Gegensatz Daten und Dokumente deckt natürlich auch nicht alles ab, er beschreibt nur
typischerweise beide (manchmal unnötig verfehdeten) Lager.

Trotzdem sollte man vorsichtig sein, die Art der Modellierung mit der Art der Speicherung zu vermischen. XML strukturiert Dokumente (mit all Ihrere Komplexität) UND Daten. Aber langfristig wird XML  -ob es nun Daten oder Dokumente speichert - bei größeren Projekten immer in Datenbanksystemen gehalten werden. Und dabei vermischen sich auch bereits die Grenzen zwischen nativen XML-DBS und relationalen mit XML-Fähigkeit. Nur DBS bieten (egal WIE nun tatsächlich das XML dort gespeichert wird) die bekannten Dinge wie Transkationssicherheit, Skalierbarkeit, Speicherungsstrukturunabhängigkeit....

Wenn man sich beispielsweise mal XML-basierte Standards RDF, SVG oder MathML anguckt, dann bekommt man bereits eine gute Ahnung von der vielseiten Anwendbarkeit von XML. Und Metadaten, Vektorgrafiken, oder mathematische Formeln wuerde ich weder in die Rubrik "Dokument" noch in die Rubrik "Daten" (im Sinne von DBS) einordnen.

Das ist ein "Kompromiss" bzw. ein Argument, das ich durchaus einsehe.

Na gut, ich auch ;-)
Nein im Ernst: Klar ist ja, dass nie etwas vollstänig in Kategorien einzuordnen ist und das man auch per se in verschiedenen Kategorien bereits ein Übel erblicken kann. Trotzdem glaube ich, dass man anhand der Dreiteilung

1. Dokumente
2. Daten
3. Konfigurationsdateien
   Ganz gut überleiten kann zu den drei großen XML-Verwendungsparadigma
4. Publishing
5. Messaging
6. Deskriptive Programmierung/Konfiguration
   Die Zuordnung ist nämlich nicht 1:1 (Publishing = Dokumente; Messaging = Daten), sondern mischt sich zunehmend (Publishing aus Datenbbanken, Messaging von Dokumenten)

Letztere schein tatsächlich zuzunehmen, wenn man sich mal so umschaut wieviel Code nun angeblich über XML-Konfiguration und XSLT-Transformation generiert wird. Ein Gebiet auf dem ich (noch) skeptisch bleibe, allerdings auch keinerlei praktische Erfahrung im XML-Bereich mit habe.

Gruß
Franz, der auch Dokumente lieber mag als Daten ;-)