Erweiterbarkeit

29. Oktober 2003, Letzte Änderung: 24. August 2009

Es wäre wirklich schön, wenn eine Technologie bereits beim ersten Entwurf ausgereift wäre. Es gäbe keine unterschiedlichen Versionen, keine Unterschiede zwischen Applikationen, kein Bedarf zum Upgrade. Aber in der Praxis wird immer eine zweite, oftmals auch eine dritte Version benötigt. Das sollte man am besten bereits beim Entwurf der ersten Version berücksichtigen.

Natürlich kann man nicht wissen, welche Erweiterungen es in der zweiten Version, und schon gar nicht, welche es in der dritten Version geben wird, aber es gibt dennoch einige Dinge, die man tun kann, um zukünftige Erweiterungen zu erleichtern, speziell dadurch, dass man bestimmte Syntaxausdrücke in der Hinterhand behält, denen man in Zukunft neue Funktionen zuweisen kann. Man kann eine Sprache dadurch zu einem gewissen Grad vorwärtskompatibel machen.

Ein einfacher Trick ist es, eine »magische Nummer« zu Beginn der Datei einzufügen, typischerweise eine Versionsnummer, sodass Applikationen, die für die erste Version geschrieben worden sind, erkennen können, wenn eine Datei nicht dieser Version entspricht. Das vermeidet zwar Missinterpretation von Daten, führt allerdings oftmals dazu, dass eine Applikation Daten, die zu neu sind, überhaupt nicht verarbeitet.

Einige Arten von Information sind zugänglich für reibungslosen Funktionsverlust. Applikationen der ersten Version beispielsweise können so entwickelt werden, dass sie sich einem gewünschten, erst in der zweiten Version implementierten Effekt im Rahmen ihrer Möglichkeiten annähern, während aktuellere Applikationen den vollständigen Effekt umsetzen.

HTML zum Beispiel verfügt über eine einfache Regel, die für Textdokumente einigermaßen gut funktioniert: Alle Texte in unbekannten Elementen werden so behandelt, als ob es einfacher Inline-Text wäre, unbekannte Attribute werden ignoriert. Entwickler neuer HTML-Versionen haben dadurch zwei Möglichkeiten, neue Entwicklungen zu integrieren. Abhängig davon, ob die beste Ausweichlösung für eine neue Funktion das Auslassen von Text oder das Darstellen als Inline-Text ist, können sie ein Element oder ein Attribut wählen. HTML hat ebenfalls eine magische Nummer am Anfang des Dokuments, und diese Methode wirkt gut genug, dass Browser nicht aufgeben müssen, wenn sie ein Dokument einer neueren Version anzeigen sollen.

CSS verfügt über eine etwas ausgereiftere Methode, denn es erlaubt Autoren in vielen Fällen, Alternativen für ältere Implementierungenen bereit zu stellen. Alte Programme lesen nur das, was sie verstehen, und übergehen den Rest, während aktuellere alles lesen, und wenn der Autor es richtig gemacht hat, überschreiben die neuen Funktionalitäten die veralteten.

In C sieht die Syntax wie folgt aus:

#ifndef FEATURE
#error
#endif

In P3P ist die Syntax wie folgt:

<EXTENSION optional="no">
  <FEATURE.../>
</EXTENSION>

Wobei FEATURE proprietär und in P3P nicht vordefiniert ist.

Eine noch besser durchdachte Methode ist, dem Autor eine Methode anzubieten, von Fall zu Fall angeben zu können, ob eine Annäherung akzeptabel ist oder nicht. Die Sprache C beispielsweise bietet ein Schlüsselwort #error, welches ein Programmierer dafür verwenden kann, dem Compiler zu signalisieren, dass eine bestimmte Funktion obligatorisch ist und dass ohne diese Funktion ein Fortführen nutzlos ist. SOAP (ein Satz von Konventionen für die Entwicklung von beschränkten XML-basierten Formaten, siehe [SOAP1.1]) bietet eine ähnliche Funktion, ebenso P3P [P3P1.0].

Siehe auch:

[P3P1.0]: Cranor, Lorrie; Langheinrich, Marc; Marchiori, Massimo; Presler-Marshall, Martin; Reagle, Joseph. The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. 10 May 2000. W3C Working Draft. URL: http://www.w3.org/TR/2000/WD-P3P-20000510/
[SOAP1.1]: Box, Don, et al. Simple Object Access Protocol (SOAP) 1.1. 8 May 2000. W3C Submission. URL: http://www.w3.org/Submission/2000/05/