Projector Management and Control
Navigation: Main-Page > XML Treiber Philosphie

XML Treiber Philosphie

1. Philosphie

Eine Software für nur einen Projektortyp zu entwickeln wäre nicht sinnvoll, daher ist es erstens unabdinglich den Quellcode flexibel hinsichtlich verschiedener Geräte zu gestalten und zweitens Mittel und Wege zur Verfügung zu stellen, um nachträglich weitere Projektoren hinzuzufügen. Dieses Thema findet man weitestgehend in jedem Programm. Gelöst werden die Anforderungen durch so genannte Treiber, Codestücke die an passender Stelle ausgetauscht werden. Nun ist es nicht Ziel der Aufgabenstellung bei jedem neuen Gerät einen neuen Quellcode zu programmieren, der die neue Funktionsweise abbildet. Gesucht ist ein Weg, der mit möglichst einfachen Mitteln in kurzer Zeit einen neuen Beamertyp dem Programm vorstellt. Noch einmal, bei dem Thema Projektortreiber geht es um die Erfassung eines neuen Typs, nicht um das Hinzufügen eines tatsächlich existierenden Gerätes. Denn wenn der Software dieser neue Typ einmal bekannt ist, können danach ohne weiteren Aufwand unzählige bestehende Beamer konfiguriert werden. Zurück zu der Frage nach simplen Wegen eines Treibers. Es ist somit die Aufgabe des Treibers, die Eigenarten des neuen Projektortyps in den softwareinternen Standard darzustellen.

2. Warum XML?

XML ist universell und weit verbreitet und somit jedermann zugänglich und bekannt. Zusätzliche Vorteile, die XML attraktiv als Beschreibungssprache für die proprietären Protokolle macht, sind die logische Bedeutung der Tags sowie die Speicherung von reinen Daten, in diesem Fall die Speicherung der proprietären Protokolldaten ohne Veränderung. Die Definition eigener Tags möglich, was somit die Anwendung der softwareinternen Semantik auf die Protokolle ermöglicht. Ein weiterer Aspekt, der auf den ersten Blick keinen weiteren Nutzen bringt, ist die flexible Darstellung von XML Dokumenten. Dies ermöglicht weiten Spielraum von einmal mit XML erfassten Daten. Zu guter letzt spricht schlicht die enge Bindung zwischen Python, der hier eingesetzten Programmiersprache, und XML dafür, diese Metasprache als einen Typus Treiber einzusetzen.

3. Funktionsklassen

Jeder Projektor hat eine bestimmte Funktionalität. Dazu ist einführend anzumerken, dass prinzipiell zwischen Funktionen und Kommandos bzw. Befehlen unterschieden werden muss. Während Funktionen wie z.B. Kontrast, Helligkeit oder Power die Fähigkeiten des Projektors beschreiben, bewirken Kommandos die Steuerung der Funktionen. Für eine computergestützte Verarbeitung ist es zusätzlich notwendig, die Arbeitsweise der verschiedenen Beamerfunktionen zu repräsentieren und somit den Kommandos ihre Semantik zu geben. Dabei werden die Kommandos in folgende Funktionstypen untergliedert:

• Funktionen der Adjust Klasse sind über Inkrementierung oder Dekrementierung, schrittweise Erhöhen bzw. Verringern, ihres Zustandes einstellbar. Die Befehlsstruktur sieht somit auch nur zwei verschiedene Parameter (+/-) vor. Diesem Typ können beispielsweise Helligkeit und Kontrast zugeordnet werden. Der Wertebereich von Adjust Funktionen ist durch das Minimum und das Maximum sowie durch eine optionale Schrittweite gekennzeichnet.
• Funktionen der Value Klasse besitzen den gleichen Wertebereich wie Adjust Funktion. Das heißt Wertemenge mit Minimum, Maximum und Schrittweite. Der Unterschied ist jedoch, dass mit Value Funktionen der Wert direkt gesetzt werden kann.
• Funktionen der State Klasse besitzen als Wertebereich mindestens zwei einstellbare Zustände. Zu diesen Funktionen zählen unter anderem Power, Source (Input) und Sprache. Diese Zustände sind direkt wählbar.
• Die Execute Klasse, als der simpelste Funktionstyp, beschreibt Fähigkeiten, welche keine Parameter benötigen sowie keine internen Zustände besitzen. Reset, Factory Reset und ähnliche einfache Funktionen sind diesem Typ zuzuordnen.
• Funktionen der Query Klasse zeichnen sich in ihrer Anwendung aus, indem sie keinerlei Übergabeparameter benötigen. Wie der Name schon sagt, senden Funktionen des Query Typs, wie zum Beispiel die Lampenbrenndauer, eine Anfrage und geben infolgedessen den Wert des angefragten Zustands zurück.
  

4. Spezifikationsmöglichkeiten der Tags

Im Allgemeinen hat jeder Projektor eine bestimmte Anzahl von Funktionen. Diesen Funktionen werden, je nach proprietären Kommunikationsprotokoll, Funktionsklassen (Adjust, State, Execute oder Query) zugeordnet die einen Wertebereich (value, state, keine) implizieren. Zusätzlich muss jede Funktion, durch die hier vorgestellten Typen ihre Antworten (confirm, value, state, error) spezifizieren. Im Endeffekt ermöglichen diese Klassifizierungen dem Programm alle Daten, die während der Arbeit mit Projektor ausgetauscht werden, zu analysieren und der Nutzerschnittstelle zur Verfügung zu stellen.

4.1 Überblick

• Funktionstyp - function type: Adjust | State | Value | Execute | Query
• Funktionsidentifikator - function id: Siehe Liste unter Punkt 9
• Befehlsparameter - command parameter: state | value | none
• Antwortparameter - answer parameter: state | value | confirm

4.2 Abhängigkeiten

5. Deklarationsregeln DTD

Grundlegend wird jede Funktionsdefinition in ein GET und SET untergliedert und dort jeweils mit REQUEST und RESPONSE beschrieben. Dabei wird eine RESPONSE durch ein COMMAND und eventuelle PARAMETER, ein REQUEST hingegen durch ein RESULT und mögliche ANSWERS beschrieben. Zur besseren Übersicht hier ein Auszug aus der Document Type Definition DTD. Auf eine komplette Definition, die alle Sonderfälle behandelt, soll hier hinsichtlich eines besseren Verständnisses verzichtet werden.

<!ELEMENT function (name, (get | set)*>
<!ELEMENT name (#PCDATA)>
<!ELEMENT set (request, response)>
<!ELEMENT get (request, response)>
<!ELEMENT request (command, parameter?)>
<!ELEMENT response (result, answer?)>
<!ELEMENT command (#PCDATA)>
<!ELEMENT parameter (#PCDATA)>
<!ELEMENT result (#PCDATA)>
<!ELEMENT answer (#PCDATA)>

6. Ein Beispiel

Das nachfolgende Beispiel zeigt schemenhaft wie eine mögliche Konfigurations datei aussehen könnte. Dieser Ausschnitt eines XML Dokuments beschreibt Teile des Kommunikationsprotokolls eines fiktiven Projektortyps. Den Kern der Beschreibung bildet natürlich die Funktionalität des Beamers, gemäß den oben vorgestellten Funktionsklassen. Das Beispiel zeigt die Darstellung des wohl komplexesten Funktionstypen State. Der im Beispiel dargestellt Teil eines XML Treibers, ist ein Vertreter einer typischen Projektor Funktionalität. Wichtig ist hier, dass die Funktion Source durch den Typ „State“ beschrieben wird. Dieser erlaubt die Definition von Zuständen. Zusätzlich ermöglicht er, Anfrageparameter sowie Antworten über das id Attribut auf den Status abzubilden.

<function id="SRC" type="State">
   <name>Source</name>
   <range type=”state”>
      <state id="1">RGB1</state>
      <state id="2">RGB2</state>
      <state id="3">Video</state>
      <state id="4">Viewer</state>
      <state id="5">S-Video</state>
      <state id="6">LAN</state>
   </range>
   <set>
      <request>
         <command parameter="state">input ####</command>
         <parameter id="1">rgb1</parameter>
         <parameter id="2">rgb2</parameter>
         <parameter id="3">video1</parameter>
         <parameter id="4">viewer1</parameter>
         <parameter id="5">svideo1</parameter>
         <parameter id="6">lan1</parameter>
      </request>
      <response>
         <result answer="confirm">ok</result>
      </response>
    </set>
   <get>
      <request>
         <command parameter="none">input</command>
      </request>
      <response>
         <result answer="state">input:#####</result>
         <answer id="1">computer1</answer>
         <answer id="2">computer2</answer>
         <answer id="3">video1</answer>
         <answer id="4">viewer1</answer>
         <answer id="5">svideo1</answer>
         <answer id="6">lan1</answer>
      </response>
   </get>
</function>

7. Werterkennung mittels Wildcardzeichen

Ein weiteres Merkmal im XML Treiber ist die Möglichkeit mit dem Wildcard zeichen ##### Parameterersetzungen zu kennzeichnen. Erscheint das Zeichen im COMMAND, sagt es aus, dass an dieser Stelle ein Ersatz stattfinden muss, um einen gültigen Befehl zu erlangen. Das heist hier wird ein Wert oder ein Zustand eingesetzt damit das Kommando vollständig ist. Umgekehrt dient das Wildcardzeichen gleichzeitig im RESULT um eine Antwort zu erlangen.

8. Zuordnung der Funktion id

Jeder neue deklarierten Funktion ist eine dreistellige eineindeutige ID zuzuordnen. Diese kann prinzipiell belibig gewählt werden. Jedoch sind folgende IDs schon voreingestellt und gelten als Bezeichnungsempfehlung. Die Klasse ist darüber hinaus eine mögliche Funktionsklasse die aber nicht zwingend bei jedem Projektortyp gleich aussehen muss und deshalb hier auch nur als Richtwert gilt.

Beachte, dass bei der Powerfunktion PWR, die Zustände in der Reihenfolge "Power On", "Power Off", "Weitere Powerzustände" angegeben werden. Dies ist notwendig um die Gruppenfunktionalitäten zu gewährleisten!!!