Sie sind hier

KOMAScript und xkeyval

Ich schreibe gerade an Klassendateien für unseren Lehrstuhl. Optionen möchte ich dabei nach dem Schlüssel-Wert-Prinzip anbieten, wie es auch die KOMAScript-Klassen jüngst anbieten. Das Paket xkeyval scheint mir recht geeignet für meine Zwecke zu sein. Es hat sich jedoch gezeigt, dass einige KOMAScript-Versionen (v2.95b) inkompatibel zu xkeyval sind; die aktuelle Version (v2.98) scheint aber mit xkeyval kompatibel zu sein, soweit ich das auf die Schnelle testen konnte.

Beim Studieren von scrkbase.dtx fiel mir auf, dass zwar das Paket keyval geladen, in der Codedokumentation aber immer wieder von xkeyval gesprochen wird. Zusätzlich habe ich gesehen, dass ein umfangreiches Sammelsurium an Makros zur Optionsverarbeitung implementiert wurde, das sich zum Teil auch mit Funktionalitäten des xkeyval-Pakets deckt.

Nun meine Fragen:

  1. Was waren die Gründe, dass ihr euch für keyval und gegen xkeyval entschieden habt.
  2. Wird KOMAScript in Zukunft weiterhin kompatibel zu xkeyval bleiben?
  3. Auf was sollte ich damit für die eigenen Klassen aufsetzen? Kann ich die KOMAScript-Funktionen (und damit den KOMA-Namensraum) verwenden?

Über eine Diskussion zu diesem Thema würde ich mich freuen.

Grüße

Bild von Markus Kohm

Was lediglich bedeutet, dass man xkeyval zusammen mit KOMA-Script verwenden kann. Das sollte eigentlich seit Version 2.96 der Fall sein.

Dass xkeyval von KOMA-Script nicht verwendet wird, hat drei Gründe.

  • Als 2002 (eigentlich bei scrlttr2 bereits 2001) mit der Implementierung der keyval-Schnittstelle in KOMA-Script begonnen wurde, gab es xkeyval noch nicht.
  • Später hat sich gezeigt, dass xkeyval ein paar Dinge macht, deren Sinn mir bis heute nicht ersichtlich ist und die mir gar nicht gefallen. Die beiden – und ich würde zwei Bemerkungen nicht gerade als immer wieder bezeichnen – Bemerkungen zu xkeyval in den Quellen beziehen sich genau darauf.
  • Es bietet nicht, was ich für KOMA-Script brauche.

KOMA-Script wird, wenn ich nicht etwa verbocke bzw. neue Böcke in xkeyval übersehe und xkeyval halbwegs kompatibel zu keyval bleibt, kompatibel zu xkeyval bleiben. Das wird schon deshalb so sein, damit Pakete, die xkeyval verwenden, auch weiterhin mit KOMA-Script verwendet werden können.

Die KOMA-Script-Funktionen für Optionen sind derzeit noch nicht dokumentiert und haben daher Beta-Status. Das heißt, dass sie sich noch ändern können. Außerdem sollte man keine eigenen keyval-Optionen anlegen, die den keyval-Namensraum "KOMA" bzw. "KOMA" verwenden. Theoretisch kann man die Anweisungen, die nicht zwingend Namensraum verwenden, nutzen. Das wäre beispielsweise \KOMAProcessOptions, wenn man als optionales Argument etwas anderes als KOMA angibt. Solange diese Anweisungen aber Beta-Status haben, geschieht ihre Verwendung auf eigenes Risiko.

Es ist übrigens geplant, scrkbase irgendwann in zwei Pakete aufzuteilen, wovon eines dann die Anweisungen enthält, die auch für andere Klassen- oder Paketautoren nützlich sind, und eines die Teile, die nur für KOMA-Script-Klassen und -Pakete zuständig sind. Vermutlich werden genau dann auch die Anweisungen, die in dem allgemeinen Paket landen, dokumentiert werden – die anderen nicht bzw. nur in der dtx-Datei für den internen Gebrauch.

BTW: Du brauchst mich nicht mit dem Pluralis majestatis anzureden. Zwar ist KOMA-Script ein Nachfolger von Script 2 und enthält deshalb eventuell auch noch Code davon (viel kann es aber nicht mehr sein), aber seit KOMA-Script bin ich der einzige, der Implementierungsentscheidungen trifft und umsetzt.

Comments for "KOMAScript und xkeyval" abonnieren