Hallo zusammen,
bei uns ist eine Diskussion aufgekommen, wie man bestimmte Informationen speichern sollte. Grundsätzlich handelt es sich bei diesen Informationen um Definitionen von Kommandos für ein Bussystem, zählt man die typspezifischen und herstellerspezifischen mit, kommt man dabei auf zurzeit an die 500, um mal eine Zahl zu nennen. Hierbei sind wir zurzeit für die Standardpflege zuständig, letztendlich soll das Ergebnis eine leicht erweiterbare vollständige Dokumentation des Bussystems sein, die sich gegebenenfalls auch firmenintern erweitern lässt (zum Beispiel mit den besagten herstellerspezifischen Kommandos). Die Definitionen bestehen dabei unter anderem aus Name, Nummer, Beschreibung, einigen Informationen über den Versand und Definitionen über ihre Zusammensetzung (welches Byte wird wie zusammengesetzt). Außerdem haben wir (letztendlich in einer weiteren Tabelle) die Information, welches Gerät welche Standardkommandos und gegebenenfalls welche zusätzlichen Kommandos implementiert.

In der Vergangenheit habe ich ein Programm implementiert, das diese Kommandos mitliest und anzeigen kann, einschließlich vielen Details, die sich unter anderem aus den Definitionen ergeben. Zu diesem Zweck habe ich damals die Kommandos als XML definiert - Kommandogruppen enthalten Kommandos, eine relativ flache Hierarchie. Im Zuge dieser vollständigen Dokumentation wäre mein Ansatz daher grundsätzlich, es bei diesem XML zu belassen - weitere Zusammenhänge kann man bei Bedarf relativ einfach mit XSLT darstellen. Wirkliche Nachteile gegenüber einer rein relationellen Darstellung sehe ich daher zurzeit nicht.

Ein Kollege ist nun aber der Meinung, XML sei nicht nur viel zu aufgeblasen und daher bei manueller Bearbeitung sehr ungünstig, sondern auch insgesamt viel zu unflexibel und arbeitet daher nun an einer Domain Specific Language (DSL), also einer Sprache, die diese Probleme beseitigen soll. Implementiert mit Ruby, so definiert man quasi die Befehle in einem Skript mit nur minimalen syntaktischen Eigenheiten. Das sieht auch nicht schlecht aus, aber ehrlich gesagt finde ich nicht, dass es einfacher als XML zu schreiben ist. Man muss sich immerhin trotzdem an gewisse syntaktische Vorgaben halten, die in meinen Augen sogar weniger intuitiv sind als die von XML. Außerdem hat man als Ergebnis ein Skript, aus dem man dann zwar wieder mit entsprechenden Mitteln andere Formate einschließlich XML generieren kann (indem man ein entsprechendes Skript schreibt) - aber den Vorteil sehe ich immer noch nicht, zumal man mit XML erstens ebenfalls beliebige Textformate generieren kann und zweitens sehr einfach einen grafischen Editor entwickeln kann, wodurch der vermeintliche Nachteil des schlechteren manuellen Bearbeitens wegfällt.
Außerdem kann man das Skript schlecht in anderen Programmen verwenden und benötigt immer eine Laufzeitumgebung, XML hingegen lässt sich fast überall problemlos bearbeiten und es lässt sich einfach ein Programm schreiben, das die Transformationen durchführt (ironischerweise zum Beispiel mit einem Ruby-Skript).

Nun hat sich unser Projektmanager letztendlich dazu entschieden, mittelfristig auf XML als primäre Datenquelle umzustellen, was ich sehr begrüße, meinem DSL-Kollegen jedoch eher Kopfschmerzen bereitet, weil er fürchtet, bestimmte Probleme ließen sich letztendlich mit XML nur mit größten Verrenkungen umsetzen. Seine XML-Erfahrung und insbesondere die in erweiterten Dingen wie XPath und XSLT ist natürlich auch beschränkt, ähnlich wie meine bezüglich Ruby und DSL.

Ergänzung:
Ich vergaß noch zu erwähnen, welchem Zweck diese Daten dienen. Aus den Definitionen soll sich eine (Text-)Dokumentation generieren lassen, sie sollen für zukünftige Programme verwendet werden können, man soll Header-Dateien für die Embedded-Abteilung generieren können, aber auch für die PC-Software-Abteilung, soll die Definitionen gegebenenfalls direkt in Programmen verwenden können, und sowohl wir PC-Software-Leute als auch die Embedded-Leute sollen die Definitionen ergänzen können.


Mich würde aber nun einmal interessieren, ob ihr irgendwann auch einmal vor einem derartigen Problem standet und wie euer Ergebnis war, oder wie ihr dieses Problem eben angehen würdet. Hat jemand Erfahrung mit DSLs, positive oder negative? Alles, was euch hierzu einfällt, interessiert mich.

Im Prinzip hast Du alle Vorteile und Nachteile der beiden Vorgehensweisen schon beschrieben.
Also für mich kommt da nur XML in Frage.

Ich will Deinem Kollegen ja nicht zu nahe treten, er sollte sich aber auch mal neuen Sachen öffnen und nicht stur auf seiner Meinung beharren.
/Sarkasmus
Kann es sein, dass er schon etwas älter ist und am liebsten in Assembler programmiert?

Das Ding ist, die DSL ist ja gerade ein von ihm in Erwägung gezogener neuer Ansatz, mit dem er experimentiert hat, der einige Probleme von XML und anderen Ansätzen lösen soll. Es soll ja durchaus Unternehmen geben, die DSLs sehr erfolgreich einsetzen, und zwar als Ersatz für XML. Insofern kann man nicht so richtig sagen, er solle sich mal neuen Dingen öffnen

Also ich kann mir nicht so richtig vorstellen, dass hier eine Domain Specific Language einen Nutzen bringt.
Für jede DSL muss es ja einen Interpreter geben, der die DSL als Input nimmt und ein Ergebnis liefert.
Dieser Interpreter müsste ja auf dem Zielsystem laufen und die Komandos direkt auf den Bus schicken.
Ausserdem müsste der Interpreter Daten auf dem Bus empfangen und wieder in die DSL übersetzen.
Ich weiss ja nicht, welche Hardware dahinter steckt, könnte mir aber vorstellen, das der Interpreter mindestens zweimal in Rudy und C/C++ programmiert wird.

Also, die Definitionen dienen keineswegs nur dazu, eine Busanbindung herzustellen. Die Geräte für den Bus würden aus den Definitionen nur ihre Header zusammengebaut bekommen und nachwievor in C programmiert werden (oder in C++ für die etwas größeren). Oder sie bekommen eben die XML-Dateien - diese kann man durchaus auch aus den Ruby-Skripten generieren. Auch die Anbindung für zum Beispiel meinen Protokoll-Analyzer findet über ein entsprechendes Interface statt und verwendet die Definitionen "nur" zur Anzeige schöner Namen, Symbole usw. und zur Anzeige einer kompletten Kommandoliste, von der aus man auch versenden kann. Außerdem soll eben eine Dokumentation daraus erstellt werden können. Zu guter Letzt haben wir außerdem ein C-Interface für die Schnittstelle, das auch von Ruby aus funktioniert, und zwar unter Windows und unter Linux. Immerhin gibt es die Überlegung, Ruby als Umgebung für Testskripte zu verwenden. Aber im Endeffekt kann man die Ruby-"Header" ja auch per XSLT aus dem XML generieren.
Ich sehe aber eben XML trotzdem eher als die Primärdatenquelle, weil es einfach vielseitiger ist und man es in vielen Fällen sowieso benutzen müsste, so dass in dem Fall bei einer Ruby-Lösung der XML-Export immer als Zwischenschritt notwendig wäre.

Vielleicht insofern mal die Frage: Ist jemand mal bei der Benutzung von XML als Datenquelle an die Grenzen von XML und/oder XSLT gestoßen? Wie sah das aus?

Noch mehr Meinungen?