Valid HTML 4.01!

Norman Rau, 28.04.2003

Xforms



Geschichte

1945 erschien ein Artikel in The Atlantic Monthly. Vannevar Bush schrieb schon dort über ein Hypertext Netzwerk “Memex”. In dessen konzeptionellen Stadium, kam der Gedanke Formulare zu verwenden, um Daten zu sammeln. Die Art der Datensammlung beschrieb er wie folgt: “One might, for example, speak to a microphone, in the manner described in connection with the speech controlled typewriter, and thus make his selections.”. Damit kann man dann später in die ungeheuren Mengen von Daten eindringen und diese verarbeiten.
In HTML 2.0 wurden erstmals Formulare, für Standardisierung der Datensammlung, in Erwägung gezogen. Im Juni 1994 aufbauend auf HTML+ waren dann Formulare beinhaltet. Am 06.04.2000 erschien die erste Xforms Draft Spezifikation mit Titel „Datamodeling Proposal for Xforms“ - gleichzeitig damit die XML Schema Spezifikation. Xforms Datentypen sollten sich für andere Anwendungsgebiete von denen in XML Schema unterscheiden. Am 15.08.2000 untersuchte das W3C wie Forms, ein Datenmodell definiert mit XML Schema plus form spezifische Merkmale, zu unterstützen sind. Im Juni 2001 erfolgte die Realisierung der „simple syntax“. Das Problem war eine notwendige redundante Spiegelung der Instanzdaten/Initialisierungsdaten als Formulardaten, durch zwei mögliche Wege. Dadurch kam es zu Problemen zwischen XML Schema Formularen und „simple syntax“ Xforms. Am 26 October 2001 wurde das XML Events Working Draft veröffentlicht als Last Call Working Draft. Am 07 December 2001 erschien das Working Draft von XForms 1.0.

Allgemeines

„What the world really needs is more love and less paperwork” (Pearl Balley)
Das Wort Xforms besitzt keine singulare Form (W3C). Formulare sind zum Daten sammeln da. Formulare repräsentieren eine strukturierten Austausch von Daten. Je interaktiver eine Webseite ist, desto mehr Formulare werden verwendet. Xforms sollen die HTML Forms ablösen.

Ziele

Xforms soll nicht rückwärtskompatibel zu früheren HTML sein. Es sei Geräte unabhängig, egal ob Maus oder Tastaturbefehle (somit onmouseover, ondblclick -> gameover). Es obliegt einer strengen Unterscheidung von Inhalt und Form und soll universell zugreifbar sein. Weiterhin sollen 20% der Funktionalität von HTML unterstützt und 80% der Notwendigkeit von Scripten unterbunden werden. Festgelegt werden standardisierte Mechanismen für einen bidirektionalen Datenaustausch und Unterstützung von verschiedenartigen Datenaustauschen. Eingabefehler sollen ohne Serveranfragen früh erkannt werden. Mit wenig Aufwand werden Formulare erschaffen, z.B.: mit einem einfachen Text Editor, einfacher Syntax, und einem besseren Umgang mit non-western Zeichencodes und unicode. Einfache Berechnungen und Ausdrücke basieren auf Formular Daten. Abhängigkeiten zwischen Datenwerten sind ausdrückbar (Datenfeld wird nur aktiviert, wenn anderes ausgefüllt wurde).
Formulare können letztendlich einfach an mehrere Benutzer und Ziele gesendet werden.

Einschränkung

HTML
 XForms
Die Abhängigkeit von script Sprachen.
  • HTML Formulare sind angewiesen auf scripts um tasks zu erledigen (z.B.: benötigte Befehle markieren, Validierung, Berechnungen, Fehler anzeigen)
  • resultiert in komplexen Dokumenten, teuer und zeitaufwändig für Programmierer
 Reduziert die Notwendigkeit von scripts auf verschiedenen Wegen.
  • eine Vorlage definieren für einfache Xpath basierte Berechnungen und Validierungen
  • besseres Benutzerfeedback des Formularstatus durch dynamische features (z.B.:optionale Sektionen)
Die Schwierigkeit Formulardaten zu initialisieren.
  • erinnern an letzten Benutzer schwierig
  • Eingaben die schon vorlagen wiederholt einzugeben ist schlecht
  • jedes Formular hat eigenen Weg Initialisierungsdaten zu definieren
  • ein leeres Formular wieder aufzufüllen bedarf der Rekonstruktion aller vorhergehenden Schritte seriell
 Formulardaten werden im XML Dokument mitgeführt, auch ausserhalb der Formulardefinition
  • kann mit XML Daten umgehen
  • Daten im Formular zu initialisieren ist einfach ein Zeiger auf die Daten im XML File
Das Encoding Format.
  • Urlencoded oder mulitpart präsentieren nur flache Datenstrukturen oder Namen/Werte Paare
  • viele Formulare aber viel komplexer
 Besser als flache Dokumentstrukturen.
  • als fundamentale Voraussetzung XML
Versteckte Annahme von einem 1 Schritt Prozess, vom Client zum Server danach Ende
  • in realer Welt ist feedback zwischendurch sehr wichtig, dauert hier aber zu lange
  • nicht als workflow verwendbar
  • in workflow Scenario muss Datenformat in jeder Instanz reinterpretiert werden
 Eröffnet verschiedene patterns
  • Formulardaten (XML File) können zu verschiedenartigen Arbeitstationen versendet werden
  • nach jedem Halt werden Daten in das Formular geladen, eröffnet Möglichkeit Formular weiter auszufüllen, danach weitersenden
  • dieser Prozess ist beliebig oft wiederholbar

Architektur










Konzepte - Schichten

Das Datenmodell (data model) ist die Struktur der Dateninstanz.

Die Dateninstanz (instance data) ist eine interne Repräsentation von den Daten, zugeordnet zu den verwandten Form Controls. Diese basiert auf XML. Sie wird ferner in Termen auf Xpath’s interner Baumpräsentation definiert. Sämtliche Formulare sammeln Daten, ausgedrückt durch instance data.
Die Nutzeroberfläche (user interface) ist die Formularpräsentation. Mit den drei Konzepten wird eine Trennung von Inhalt und Form eingeführt.

Zusammenhang zwischen XForms und Xpath

Xpath ist bekannt als Schicht zwischen XSLT und Xpointer. Die Formulare brauchten grössere Strukturen als mit einfachen „name-value“ Paaren darstellbar war. Notwendig wurden damit Verbindungen von den Dateninstanzen zu Teilen der Datenstruktur. Die Xpath Notation unterstützt den Rahmen für Berechnungen, Validierungen, nur Lese Daten oder Sichtbarkeit von Befehlen. Die XML Schema Datentypen unterstützen Parameter zum Daten sammeln (patterns) und Längeneinschränkungen.

Vergleich XForms und XSLT



XSLT
 XForms
XSLT wird beschrieben durch Terme in 3 Bäumen -
und erschaffen durch das Parsen von XML Dokumenten.
 Xforms kombiniert Eingabe und Ausgabe im selben Baum.
1.    Vom Source-Dokument wird ein source-tree und ein stylesheet-tree in den Speicher geparst
 1.    Aus einer Eingabe Quelle wird (inline oder einem XML Dokument auf dem Server) die Dateninstanz in den Speicher geparst
2.    Ein result-tree wird aus den beiden erschaffen.
 2.    Die Dateninstanz fordert somit eine Interaktion mit dem Benutzer und speichert jegliche Änderung der Daten.
3.    Der result-tree wird serialisiert - typischerweise in ein neues XML Dokument. 3.    Die Dateninstanz wird beim Abschicken serialisiert, typischerweise in XML und wird an den Server gesendet.
  • Serialisierung der Daten auch als multipart/form data oder URL codiert

Xforms submit protocol


Das Xforms submit protocol definiert wie die Daten gesendet und empfangen werden und beinhaltet auch Daten zurückzustellen und Formularausfüllung wieder aufzunehmen.

Hauptaspekte

Der Autor kann mit Element basierter deklarativer Syntax
    dem Benutzer eine Nachricht zeigen
    zu einer neuen URI navigieren
    den Wert eines Dateninstanzknotens ändern
    Formulare über ein scripting interface ändern
    eine Wiederberechnung, nochmalige Validierung, Bildschirmwiederaufbau fordern
    Übermitteln oder löschen aller oder bestimmter Instanzdaten.

XForms trennt das Ziel, die Präsentation und die Daten.
Es herrscht eine exzellente XML Integration (auch in XML Schema).
Die Notation erfolgt in XML Syntax und es werden konsistente XML basierte Formate für eingehende Daten benutzt.
Die Daten werden in XML und anderen Formaten übermittelt. Es liegen feste Typendefinitionen vor.
Weiterhin gibt es Unterstützung für handhelds, TV, Browser, Drucker, Scanner.
Unterstützt werden mehrere Seiten per Formular und mehrer Formulare per Seite. Ein Seitenwechsel erfolgt ohne den Server zu kontaktieren.
Wiederverwendbarkeit und Wiederverwendung der Formulare für unterschiedliche Plattformen ist gewiss.
Ein Formular wird als Datei abgespeichert, kann später oder weiter ausgefüllt werden, [auch mit einem anderem user interface], [oder auf einer anderen Plattform].
Selbst definierte Befehle können erschaffen werden, mit ähnlichem Verhalten wie standard Befehle

Integration

Xforms sind kein eigenständiger Dokumenttyp, sondern ein Tag Set was in andere Dokumenttypen eingebunden werden kann. Eine Integration erfolgt also mit anderen XML Tag Sets (XHTML, SVG, SMIL).
XHTML 2.0 ist keine Weiterführung von XHTML 1.x oder HTML 4.x, sondern eine modulare Sprache, so daß Tag Gruppen in Form von seperaten Einheiten eingegliedert werden. Eigene XHTML Module für Formulare und Frames fehlen hier. XHTML wird benutzt, um Geräte zu kontrollieren und verringert somit die Notwendigkeit von Gerätetreibern.

Anwendungen

25.03.2002: E-XML-Media - XFE
02.07.2002: Business Web Software - AchieveForms 
23.10.2002: FormsPlayer, XForms processor plug-in für Internet Explorer 6 SP 1
19.12.2002: X-Smiles  Version 0.71
24.03.2003: Das Chiba Projekt - Web-basierter XForms Processor
31.03.2003: The Apache Cocoon XMLForm module
01.04.2003: S - erste Version Chiba/Cocoon (Chicoon)
04.04.2003: Type.a Corp. - Xero
10.04.2003:  IBM - XML Forms Package
15.04.2003: Orbeon - OXF 1.0
Cardiff - Liquid Office

Mozquito - XML Web-Access 2.0

Quellen