SourceForge.net Logo 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:

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

4.2 Abhängigkeiten

 
Klasse Adjust
Klasse Value
Klasse State
Klasse Execute
Klasse Query
Range value value state - -
Get Comand erforderlich optional optional - erforderlich
Set Command erforderlich erforderlich erforderlich erforderlich -
Get Parameter keine keine keine - keine
Set Parameter inc(+) | dec(-) value state keine -
Get Result value | error value | error state | error - value | state | string
Set Result confirm (ok) | value | error confirm (ok)| confirm (ok) | state | error confirm (ok) | error -

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!!!

Funktion ID Klasse Gruppe Beschreibung
Power PWR State General Ein- und Ausschalten
Reset RST Execute General Einstellungen zurücksetzen
Rear REA State General Rückprojektion
Ceiling CEI State General 180° Bilddrehung
Source SRC State General Bildquelle wählen.
Source Search SRS Execute General Input Suche
Contrast CON Value Screen Kontrast
Brightness BRT Value Screen Helligkeit
Color Hue HUE Value Screen Rot und Grün Balance
Color Temp. CLT Value Screen Farbtemperatur
Sharpness SHP Value Screen Bildschärfe einstellen.
Keystone KEY Value Screen Trapezkorrektur einstellen.
Picture Mute PMT State Screen Bild abschalten.
Width WID Value Screen Bildbreite
Horiz. Position HPO Value Screen Bildposition horizontal
Vertical Pos. VPO Value Screen Bildposition vertikal
Magnify MAG Value Screen Vergrößerung einstellen.
Freeze FRE State Screen Standbild
Format FOR State Screen Seitenverhältnis auf 16:9
Volume VOL Value Audio Lautstärke einstellen.
Mute MUT State Audio Stummschalten.
Treble TRE Value Audio Höhen
Bass BAS Value Audio Tiefen
Loudness LOU State Audio Höhen u. Tiefenverbesserung
OnScreenDisplay OSD State Detail On Screen Display
Language LAN State Detail Sprache wählen
Lamp Time LMT Query Detail Lampenbrenndauer
Remaining Lamptime RLT Query Detail verbleibende Lampenbrenndauer
Unit On Time UOT Query Detail Betriebsstunden
Temperature TEM Query Detail Interne Temperatur
Status STA Query Detail Statusabfrage