Start

Unternehmen

ERP / PPS / Prozesse

Business Intelligence

Server-Technologien

Software-Technologien

Technologie-Beratung

Individual-Software

Produkte

Comelio GmbH
Rellinghauser Straße 10
D-45128 Essen
Deutschland
Fon: 0201-437517-0
Fax: 0201-437517-10
info@comelio.com

Comelio GmbH
Goethestraße 34
D-13086 Berlin
Deutschland
Fon: 030-921019-85
Fax: 030-921019-89
info@comelio.com

Comelio GmbH (Ecos)
Glockengießerwall 17
D-20095 Hamburg
Deutschland
Fon: 040-4689908-91
Fax: 040-4689908-95
info@comelio.com

Comelio GmbH (Ecos)
Mainzer Landstraße 27-31
D-60329 Frankfurt
Deutschland
Fon: 069-2475030-35
Fax: 069-2475030-39
info@comelio.com

Comelio GmbH (Ecos)
Stiglmaierplatz/Dachauer Str. 37
D-80335 München
Deutschland
Fon: 089-2000154-90
Fax: 089-2000154-94
info@comelio.com

Comelio GmbH (Ecos)
Liebknechtstr. 33
D-70565 Stuttgart
Deutschland
Fon: 0711-252534-20
Fax: 0711-252534-24
info@comelio.com

Comelio-Blog > XML Schema > XForms

Web-Formulare mit Hilfe von Xforms und XML Schema

XForms stellt eine noch wenig verbreitete Technologie dar, mit deren Hilfe anspruchsvolle und interaktive Formulare für den Browser-Einsatz erstellt werden können. Völlig auf XML basierend und verschiedene W3C-Technologien wie XML Schema, XPath, DOM und XHTML einsetzend, bieten sie eine Funktionalität, welche die Entwicklung von Web-Formularen sehr verändert. Die erhöhte Funktionalität wird mit einer deutlich komplexeren Syntax für die reine Erstellung erkauft. Was allerdings die Verarbeitung hinsichtlich Validierung und Interaktivität anbetrifft, so ist die Vereinfachung besonders erstaunlich. Dieser Artikel soll Sie von herkömmlichen HTML-Formularen weg und zu neuen XForms hinführen.

Kontakt Anrede* Herr Frau Vorname* Nachname* Firma E-Mail* Tel-Nr. Bereich* Comelio-Blog > XML Schema > XForms Freitext

XForms – die neue Benutzerschnittstelle im Netz

Oftmals gelingt es nicht, Web-Anwendung wie gewünscht umzusetzen, weil HTML-Formulare nicht die gleiche komplexe Benutzerführung erlauben wie Formulare für Desktop-Anwendungen. Die Entwicklung von Oberflächen kann bei hohen Anforderungen vergleichsweise umständlich werden, JavaScript oder verschiedene getunnelte Unterformulare erfordern kann. Als Lösung bieten sich hier verschiedene Technologien wie z.B. JavaScript oder natürlich entsprechend komplexe Programmstrukturen an, die serverseitig HTML-Formulare erzeugen, validieren, neu aufbauen und auch versuchen, interaktive Benutzeroberflächen zu entwickeln. In diesen Fällen kann es sein, dass zwar eine Web-Anwendung das Ziel der Arbeit ist, aber letztendlich doch nicht das Ergebnis erreicht wird, das eigentlich angestrebt war. Teilweise schnürt man dann auch schnell eine Desktop-Lösung, was für Web-Entwickler schade ist, weil sie nur mit entsprechendem Fachwissen an einem solchen Projekt teilnehmen können. Ebenso kann es sein, dass unterschiedliche technische Voraussetzungen auf Server-Seite notwendig sind, welche bestimmte Web-Technologien erst einsatzfähig machen. XForms bietet als Technologie nun genau eine Möglichkeit, auf Basis einer interessanten Architektur interaktive und sehr komplexe Formulare für Web-Anwendungen zu entwickeln, die sich zudem in unterschiedliche Rahmenarchitekturen einbinden lassen und auch robust gegenüber Änderungen der Basis-Programmiersprache sind. In vielen Punkten ähneln sie traditionellen HTML-Formularen, doch in Wirklichkeit lassen sie sich nur mit HTML / JavaScript-Formularen vergleichen.

Vorteile von XForms

Wie es sich für neue Technologien gehört, so hat der Erfinder eine ganze Handvoll (oder sogar noch mehr) Vorteile bereit, die sich mit seiner Erfindung umsetzen lassen. Diese Vorteile umfassen laut W3C [1] die folgenden Punkte, die ich kurz zusammenfasse und sofort auch kommentiere. Die Verwendung von XForms bietet noch einige Herausforderungen, die mir bei entsprechenden Seminaren immer wieder aufgefallen sind.

Verbesserung der Benutzerfreundlichkeit bzw. Anreicherung des Benutzererlebnisses: Durch die Integration von Validierungs- oder Berechnungsregeln, welche unmittelbar nach Verlassen eines Feldes ausgeführt werden können, erspart man dem Besucher Zeit, seine Daten erst zum Webserver zurückschicken zu müssen. Dies kann zwar weitestgehend auch von JavaScript erfüllt werden, muss jedoch für verschiedene Browser möglicherweise angepasst werden. Oft gibt es auch in Unternehmen Security Policies oder Vorgaben, die die das Abschalten von JavaScript vorschreiben. Durch die einfache Installation eines Plug-Ins können die XForms dagegen sofort verwendet werden. Dies hat allerdings den Nachteil, dass dieser Plug-In auch tatsächlich vorhanden sein muss. Sofern Einigkeit darüber besteht, dass dieses Plug-In ein notwendiger Bestandteil eines Software-Projekts ist und nicht in engen Sicherheitsmaschen eines Systems hängen bleibt, ist dies durchaus ein gangbarer Weg. Insgesamt dürfte wie bei JavaScript und auch bei SVG vermutlich die Situation auch weiterhin bestehen bleiben, dass ausschließlich in Intranet-Projekten XForms zum Einsatz kommen und ansonsten aufgrund der Benutzbarkeit und Sicherheitsbedenken weiterhin die hergebrachten HTML-Formulare verwendet werden.

Es ist eine XML-Technologie. Die Verarbeitung der eigentlichen Formulardaten ist in verschiedenen Programmiersprachen möglich, doch wenn es nur darum geht, Daten einer in XML-Struktur zu sammeln oder zu überarbeiten, reicht XForms bereits aus und man muss nur wenig zusätzliche Programmarchitektur bereitstellen.

Kombination von XML-Technologien. Durch die vielseitige Integration von XML-Technologien ist der Umstieg für XML-erfahrene Programmierer sehr einfach und lässt sich die Technologie schnell anwenden. Dies betrifft die Beschreibung und Validierung mit XML Schema und die Lokalisierung mit XPath.

Geräteunabhängigkeit. Da die Verwendung von XForms hauptsächlich innerhalb eines Plug-Ins, eines eigenen Browsers bzw. unter Verwendung einer externen Software funktioniert, bleibt der eigentliche Quelltext, der für das Formular verwendet wird, unberührt, sobald eine solche unterstützende Software ausgetauscht oder das Anzeigegerät, auf dem die Software installiert ist, gewechselt wird. Da es sich zurzeit um eine junge Technologie handelt, muss man leider immer genaueste Erkundigungen einholen, welcher Syntaxumfang unterstützt wird, sodass von einer wirklichen Unabhängigkeit in technischer Hinsicht noch nicht geredet werden kann. Viele mögen hier auch anführen, dass es keine Unabhängigkeit geben könne, wenn man für die Verwendung unbekannte bzw. noch nicht sehr weit verbreitete Plug-Ins verwenden muss. Wenn man sich allerdings vorstellt, dass die Verwendung von XForms so allgegenwärtig wäre wie der PDF-Einsatz, dann gewinnt dieses Argument ein ganz anderes Gewicht. Der Quelltext dieses Artikels wird mit dem formsPlayer für den Microsoft Internet Explorer getestet, doch in der Linkliste am Ende finden Sie eine Reihe von Implementierungen für andere Browser.

Einfachere Erstellung von komplexen Formularen. Es besteht die Möglichkeit, automatische Validierungen, Berechnungen und interaktive Bereiche in einem Formular mittels einer deklarativen XML-Syntax anzugeben. Dies führt dazu, dass tatsächlich im Vergleich zu einer "richtigen" Programmiersprache, in der die Formulare serverseitig zusammengesetzt oder client-seitig aufgebaut werden, eine einfachere Syntax nötig ist, um gleichermaßen komplexe Formulare zu entwerfen. Dies ist richtig und voll zu unterstützen - sobald man die Syntax beherrscht. Sie ist tatsächlich nicht sehr schwierig, doch so einfach, wie dieser Vorteil klingt, ist sie bedauerlicherweise auch nicht. Da es auch nur zwei englische Bücher und kein einziges deutsches Werk zu diesem Thema gibt, dürfte sich das Erlernen der Syntax noch auf der Ebene des Versuch-und-Irrtum-Vorgehens befinden.

Einfache XForms-Elemente

Die Ähnlichkeit der XForms-Elemente mit den HTML-Formularelementen ist überraschend und erleichtert den Einstieg in XForms sehr. Nur ein Umstand macht die Arbeit für Design-bewusste und kontrollinteressierte Kollegen möglicherweise zunächst unangenehm: Das genaue Aussehen hängt von der Darstellungsweise durch das Ausgabegerät (PDA, Handy, Browser) und einigen Einstellungen in der XForms-Syntax, nicht jedoch ausschließlich von den Vorgaben des Autors ab.

Einfache Textfelder schreiben sich in HTML z.B. mit

Vorname: <input type="text" name="vorname">

und in XForms mit

<input ref="firstname"><label>First name:</label></input>

, wobei die Beschriftung – wie in anderen Elementen auch – mit dem label-Element gespeichert wird und sich das ref-Attribut mit einem XPath-Ausdruck auf einen Knoten im XML-Dokument bezieht. Eine Textarea in HTML

Nachricht: <textarea name="nachricht" rows="20" cols="80"></textarea>

wird in XForms zu

Nachricht: <textarea ref="message"><label>Nachricht:</label></textarea>

. Optionsschalter wandeln sich von

Anrede: <input type="radio" name="anrede" value="h"> Herr
<input type="radio" name="anrede " value="f"> Frau

in XForms zum etwas seltsam anmutenden select1 (wähl-eins)-Element

<select1 ref="anrede">
   <label>Anrede:</label>
   <item>
      <label>Herr</label><value>h</value>
   </item>
   <item>
      <label>Frau</label><value>h</value>
   </item>
</select1>

Auswahlmenüs oder Kontrollkästchen werden über verschiedene zusätzliche Attribute für die Mehrfachauswahl oder die Darstellung angegeben, wobei allerdings das Plug-In entscheidet, welche genaue Darstellung gewählt wird. So würden aus einem Auswahlmenü in HTML

Monat:
<select multiple name="Fruehling">
   <option value="Mar">März</option>
   <option value="Apr">April</option>
</select>

in XForms syntaktisch der nachfolgende Quelltext werden, wobei die tatsächliche Ausgabe als Menüliste durch die Angabe appearance="minimal" angefordert wird, aber nicht garantiert werden kann.

<select ref="Fruehling" appearance="minimal">
   <label>Monat:</label>
   <item><label>März</label><value>Mar</value></item>
   <item><label>April</label><value>Apr</value></item>
</select>

Schließlich gibt es natürlich auch Elemente für die Dateiauswahl <upload ref="attachment"><label>File:</label></upload>, Passworteingabe <secret ref="pw"><label>Password:</label></secret> und natürlich Schaltflächen

Schaltflächen: <trigger><label>Show</label>
   <h:script ev:event="DOMActivate" type="text/javascript">show()</h:script>
</trigger>
oder
<trigger ev:event="DOMActivate" ev:handler="#show">
   <label>Show</label>
</trigger>

Insbesondere die Schaltflächen sind nicht nur für den einfachen Versand oder das Löschen der Einträge zu verwenden, sondern dienen einer Interaktivität, die ansonsten nur mit JavaScript eingerichtet werden könnte. Dazu zählt auch Ein- und Ausklappen von Formularteilen zur besseren Navigation sowie zur Benutzerführung innerhalb des Formulars.

Ein Einstiegsbeispiel

Gemäß des Ihnen bekannten Sprichworts von der Syntax und der 1000 Worte, beginne ich mit einem konkreten Beispiel, um die grundlegende und auch verblüffende Funktionsweise von XForms vorzuführen. Für „Hallo Welt“ gibt es leider aufgrund der Textkürze sehr wenig Einsatzmöglichkeiten, aber die Killer-Applikation einer Visitenkarte tut es auch. Informationen wie Name, Adresse und Geburtsdatum sollen einer XML-Datei direkt auf die Festplatte geschrieben werden, wobei das in Abb. 1 gezeigte XML Schema die Datenstruktur bildet.

Schema einer Visitenkarte

Die wichtigsten Prinzipien für XForms sind relativ einfach. Lediglich die fortgeschrittenen Themen wie Ereignisbehandlung und Interaktion stellen Herausforderungen dar. Ein Formular wird in eine XHTML-Datei eingebunden, wobei auf verschiedene W3C-Technologien zurückgegriffen wird. Dazu zählen das XML Schema, die DOM-Ereignisse (und einige mehr) sowie natürlich XForms selbst. Die Namensräume mit passenden Präfixen bindet man in das HTML-Element ein. Danach benötigt man für das jeweilige Ausgabegerät eine Verknüpfung und muss den Präfix des aktuellen XForms-Namensraums bei diesem Ausgabegerät anmelden. In unserem Fall ist es der unter Windows sehr einfach zu installierende (herunterladen, doppelklicken etc.) formsPlayer für den Internet Explorer (weitere Plug-Ins oder Browser sind am Artikelende in einer Liste verzeichnet).

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ev="http://www.w3.org/2001/xml-events" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:xs="http://www.w3.org/2001/XMLSchema" 
      xmlns:xf="http://www.w3.org/2002/xforms">
  <!-- Einbinden als Object -->
  <object id="FormsPlayer" classid="CLSID:4D0ABA11-C5F0-4478-991A-375C4B648F58">
    <div class="attention">FormsPlayer konnte nicht geladen werden</div>
  </object>
  <!-- Anmeldung des aktuellen XForms-Namensraums beim FormsPlayer -->
  <?import namespace="xf" implementation="#FormsPlayer"?>

Minimal muss ein model-Element muss dann im head-Bereich erscheinen, in dem man entweder auf eine XML Schema-Datei verweist wird und / oder eine leere, quasi beispielhafte Instanz / Gussform der erwarteten XML-Daten angibt. Diese befinden sich wiederum im Kind-Element instance. Da unser Formular zusätzlich Standarddaten enthalten soll, die nachher im Formular erscheinen sollen, gibt es sowohl einen Verweis als auch eine solche Gussform. Diese Gussform sehen Sie im nächsten Quelltext. Weitere model-Elemente könnten Textbausteine oder Elemente enthalten, die nachher für die Ausgabe von Auswahllisten benutzt werden können, selbst allerdings nicht übertragen oder gespeichert werden sollen. Dies sind XML-Bestandteile, die im Formular über einen XPath-Ausdruck aufgerufen werden, aber wie Textbausteine fungieren. Sollen Daten verschickt werden, muss innerhalb vom Element model wenigstens ein submission-Element zu finden. Hat man mehrere Schaltflächen für den Versand, tauchen dementsprechend mehrere solcher Elemente auf. Diese könnten bspw. unterschiedliche XPath-Ausdrücke für den Versand verwenden und nur Teile der Daten zum Server transportieren lassen. Die aktuellen Instanzdaten sollen einfach auf der Festplatte gespeichert werden.

<head>
  <title>Visistenkarte</title>
  <xf:model id="vk" schema="visitenkarte.xsd">
    <xf:instance>
      <Visitenkarte xmlns="">
        <Anrede>Herr</Anrede>
        <Name>
          <Vorname>Anton</Vorname>
          <Nachname>Ebenhof</Nachname>
        </Name>
        <Alter>33</Alter>
        <!-- Adresse und Geburtstag -->
      </Visitenkarte>
    </xf:instance>
    <xf:submission id="sub1" method="put" action="visitenkarte.xml" replace="none" indent="true" encoding="ISO-8859-1"/>
  </xf:model>
</head>

Das Ergebnis des Formulars sieht man in der Abb. 2, wobei die Werte bereits aus der eingebundenen XML-Instanz als ausgelesen und in das Formular eingetragen werden. Dies erspart einerseits Tipparbeit bei Testläufen und zeigt, wie man Standardwerte oder Vorgabewerte für XML-Aktualisierungsaufgaben in das Formular bringen kann.

Formular einer Visitenkarte

Jedes Element bezieht sich auf eine Struktur in den Instanzdaten eines bestimmten Modells, was in den zwei Attributen ref und model anzugeben ist. Bezeichnung bzw. Hinweistext ist für jedes Formularelement im label-Element anzugeben, wobei bei umschließenden Formularelementen wie der nachfolgenden Auswahlliste dieses Label sowohl für das gesamte Element als auch für jeden einzelnen Eintrag auftritt.

<body>
<xf:select1 model="vk" ref="/Visitenkarte/Anrede" appearance="full">
  <xf:label>Anrede</xf:label>
  <xf:item>
    <xf:label>Herr</xf:label>
    <xf:value>Herr</xf:value>
  </xf:item>
  <xf:item>
    <xf:label>Frau</xf:label>
    <xf:value>Frau</xf:value>
  </xf:item>
</xf:select1>

Zusätzlich sind für die verschiedenen Formularelemente auch weitere Angaben wie Verwendung eines Tastaturkürzels (Attribut accesskey), Hilfetext (Element help) oder Hinweistexte (Element hint) möglich. Die genaue Darstellung der Texte sowie möglicher Fehlermeldung ist implementationsbedingt.

<xf:input model="vk" ref="/Visitenkarte/Alter"  ev:event="DOMActivate" accesskey="a">
  <xf:label>Alter</xf:label>
  <xf:help>Bitte als Zahl eingeben</xf:help>
  <xf:hint>Wie alt sind Sie?</xf:hint>
</xf:input>

Nachdem man die einzelnen Formularelemente aufgebaut hat, folgt minimal eine Schaltfläche für den Versand. Diese bezieht sich auf ein innerhalb des Modells bekannte Versandart in einem submission-Element, was den Vorteil besitzt, verschiedene Versandarten und damit auch verschiedene Verarbeitungsmöglichkeiten anzubieten. Die Transportwege verlaufen dann über die weit verbreiteten Angaben post und get sowie multipart-post, form-data-post, urlencoded-post oder put für den Dateiversand.

<xf:submit submission="sub1">
  <xf:label>Speichern</xf:label>
</xf:submit>

Im aktuellen Beispiel erhält man einen Warnhinweis, dass XML-Daten im Dateisystem zu speichern sind. Sollte ein Fehler auftreten, der sich auf die Datenstruktur und die Datentypen bezieht, erscheint stattdessen eine entsprechende Fehlermeldung.

Speichern einer XML-Datei

Schließlich findet man, wenn alles funktioniert, eine XML-Datei mit den verschickten Visitenkartendaten im Dateisystem. Andere Möglichkeiten sehen vor, die Daten zu versenden und – wie andere Formulardaten auch – in einer entsprechenden Datei z.B. in PHP zu verarbeiten. Die XForms-Daten befinden sich dort in ihrer XML-Darstellung in der $HTTP_RAW_POST_DATA-Variable. Alternativ lässt sich auch die $_POST-Variable befüllen, wenn man das method-Attribut des submission-Elements vom Wert application/x-www-form-urlencoded auf urlencoded-post setzt.

Interaktion mit DOM-Ereignissen

Neben der reinen Gestaltung von Formularen bzw. der Zuordnung von Formularelementen zu XML-Strukturen eröffnet sich durch die Integration der Ereignisse eine ungeheure Vielfalt von möglichen Formularen. Dies betrifft in Abhängigkeit des Ereignistyps auf der einen Seite interaktive Formulare und auf der anderen Seite spezielle Korrektur-, Verarbeitungs- und Validierungsmechanismen. Raffiniert an diesen Möglichkeiten ist insbesondere die Integration von solchen interaktiven Strukturen direkt in die XForms-Syntax, sodass man sich vielerlei Arbeit clientseitig mit JavaScript und serverseitig mit belieben Programmiersprachen sparen kann.

An einem sehr einfachen Beispiel soll die Interaktion mit einem Benutzer angeführt werden. Durch die Verwendung von Schaltflächen wie sie auch in diesem Beispiel zum Einsatz kommen lassen sich auch Benutzerschnittstellen mit „Füge Element zum Warenkorb hinzu“, „Trage neue Aufgabe ein“ oder „Bearbeite aktuelle Adresse“ realisieren, sodass man bei entsprechend guter Beherrschung der XForms-Syntax ganze (Mini-)Anwendungen in einem Formular umsetzen kann.

Mit Hilfe eines Schalters lassen sich passend zu Schaltflächenaktionen Bereiche des Formulars dynamisch ein- und ausblenden. In geschickter Kombination kann man dies sogar nutzen, um Benutzer durch ein Formular zu führen, das ansonsten mehrere einzelne Seiten erfordert hätte oder sogar – mit zusätzlicher fortgeschrittener Syntax - verschiedene Varianten von Wegen umzusetzen. Im Beispiel ist dies sehr einfach. Entweder man gibt seine Adresse in die Visitenkarte ein oder sie wird als Beschriftung / lesbarer Text ausgegeben. Die einzelnen Fälle bzw. Formularbereiche lagern in einem case-Element, das einen speziellen ID-Wert hat, welcher wiederum von einem anderen Schalter in einem case-Attribut aufgerufen wird. Das DOMActivate-Ereignis zählt zu den in XForms nutzbaren Ereignissen und ist sicherlich eines der wichtigsten, weil es von einem Schaltflächenklick oder einen Aktivierungs-/Markierungsvorgang ausgelöst wird.

<xf:group ref="/Visitenkarte/Adresse" model="vk">
  <xf:switch>
    <!-- Fall 1 -->
    <xf:case id="bearbeiten">
      <xf:label>Wo wohnen Sie?</xf:label>
      <br/>
      <!-- Eingabefelder für Strasse, PLZ, Stadt -->
      <xf:trigger>
        <xf:label>Ausgeben</xf:label>
        <xf:toggle ev:event="DOMActivate" case="ausgeben"/>
      </xf:trigger>
    </xf:case>

Während im ersten Fall die Eingabefelder für die Erfassung der Adresse angezeigt werden, wird im zweiten Fall eine eingegebene Adresse als Text ausgegeben. Das output-Element ist ein Tausendsassa, das für verschiedenste Zwecke sinnvoll eingesetzt werden kann. Bspw. lässt es sich für das Ergebnis von automatischen Berechnungen wie Produktmenge * Preis über alle im Warenkorb befindlichen Einheiten gut verwenden. Im aktuellen Fall gibt es nur die vorhandene Adresse aus.

   <!-- Fall 2 -->
    <xf:case id="ausgeben">
      <xf:label>
          Adresse: <xf:output ref="Strasse"/> <xf:output ref="PLZ"/>  <xf:output ref="Stadt"/>
        <br/>
      </xf:label>
      <xf:trigger>
        <xf:label>Bearbeiten</xf:label>
        <xf:toggle case="bearbeiten" ev:event="DOMActivate"/>
      </xf:trigger>
    </xf:case>
  </xf:switch>
</xf:group>

Ausgabe von Schaltflächen

Interaktion mit dem Benutzer

Bewertung

Jeder soll natürlich seine eigene Meinung zu dieser Technologie finden, doch nach meiner Einschätzung bietet XForms ein großes Einsatzpotenzial für die Erstellung von interaktiven, komplexen Formularen. Im Internet ist der Einsatz natürlich noch keineswegs zu empfehlen, solange die Browser nicht automatisch ein Plug-In besitzen. Für den Intranet-Einsatz oder für die Entwicklung von Web-Anwendungen im Intranet-ähnlichen Bereich erlauben sie eine schnelle Entwicklung und bieten für viele Aufgabenstellung erstaunlich einfache Lösungen. Da die Syntax letztendlich doch nicht so einfach ist wie das W3C behauptet (welche Syntax ist schon – von HTML mal abgesehen – einfach?) und es noch kein ausreichendes Lernmaterial gibt, kämpft man an vorderster Front, wenn man sich für sich oder für einen Kunden für XForms entscheidet. Allerdings ist es auch wiederum so brandneu, dass man die Chance hat, eine überaus neue Technologie zu benutzen und beim Goldgräbertum mitzumachen.

Links

1. Vorteile: http://www.w3.org/MarkUp/Forms/2003/xforms-faq.html#advantages
2. Startseite http://www.w3.org/MarkUp/Forms/
3. Einführung http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html.en
4. Standard http://www.w3.org/TR/xforms/
5. X-Smiles (für Java, eigener Browser) http://www.x-smiles.org/
6. FormsPlayer (Plug-In für IE) http://www.formsplayer.com/
7. Novell XForms Explorer (für Java) http://ftp.novell.com/pub/forge/xforms-explorer/docs/home.html
8. Oracle (Plug-In für IE) http://otn.oracle.com/tech/wireless/mobilebrowser.htm
9. Sun OpenOffice/StarOffice http://download.openoffice.org/680/index.html