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:
Über eine Diskussion zu diesem Thema würde ich mich freuen.
Grüße
KOMA-Script ist inzwischen kompatibel zu xkeyval
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.
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 alsKOMA
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.