DE60011479T2

DE60011479T2 - Xml-roboter

Info

Publication number: DE60011479T2
Application number: DE60011479T
Authority: DE
Inventors: Philipp Kutter
Original assignee: Individual
Current assignee: Individual
Priority date: 2000-08-02
Filing date: 2000-08-02
Publication date: 2005-06-09
Anticipated expiration: 2020-08-03
Also published as: EP1307828B1; JP2004505379A; US7340728B2; CA2417752A1; ATE268921T1; EP1307828A1; WO2002010975A1; DE60011479D1; HK1060410A1; CN1195278C; AU2000260103A1; CN1454357A; US20020111965A1

Description

GEBIET UND HINTERGRUND DER ERFINDUNG
Die Erfindung betrifft ein Verfahren, ein System und eine Vorrichtung zur direkten Ausführung von XML-Dokumenten nach Anspruch 1 und 7–9.
Grundlagen von XML
XML wird als eine Untermenge des SGML-Formats definiert. Kurz gesagt ermöglicht es XML, das Format von Dokumenten zu definieren, die mittels sogenannter Tags strukturiert sind. Während XML sowohl eine physikalische als auch eine logische Struktur von Dokumenten definiert, liegt im Rahmen der vorliegenden Erfindung das Schwergewicht auf der logischen Struktur, wobei allerdings die bereitgestellten Mittel für die physikalische Struktur wiederverwendet werden. Von der physikalischen Struktur abstrahierend wird XML verwendet, um sowohl die Dokumenttypdefinition (DTD) als auch XML-Dokumente zu erhalten. Eine spezifische DTD T wird verwendet, um XML-Dokumente in jene zu klassifizieren, welche in Bezug auf T gültig sind, und jene, welche dies nicht sind. Man sagt Dokumente von DTD T kurz für jene, die in Bezug auf T gültig sind. Die logischen Aspekte einer DTD definieren Elemente und Attribute. Jedes Dokument eines derartigen Typs (angegeben mittels einer DTD) muss nur Instanzen der definierten Elemente enthalten, und die Attribute und die Zusammensetzung der Elemente müssen mit der DTD übereinstimmen. Als Beispiel könnte eine DTD T, welche ein Element A definiert, mit einer Zusammensetzung aus untergeordneten Elementen X, Y und Z und Attributen b und c von Element A in XML folgendermaßen notiert werden:
wobei #PCDATA die Art von Daten definiert, die für Attribute b und c zulässig ist. Ein Dokument der oben dargestellten DTD T kann nun Instanzen des Elements A enthalten. Eine Instanz des Elements A besteht aus dem Start-Tag <A ...> und einem End-Tag </A>. Innerhalb des Start-Tag werden die Werte der Attribute angegeben, und zwischen dem Start-Tag und dem End-Tag müssen Instanzen der zusammensetzenden Elemente angegeben werden. Ein Dokument vom Typ T kann demnach Instanzen von A enthalten, welche aussehen wie folgt:
wobei die exakte Form von X-, Y- und Z-Instanzen durch entsprechende Elementdefinitionen in der DTD T angegeben wird.
Die Leistungsfähigkeit von XML ist zum Teil auf die Tatsache zurückzuführen, dass die Definition von Elementzusammensetzungen rekursiv sein darf. Zur Veranschaulichung werden einige Zusammensetzungsmöglichkeiten vorgestellt und verwendet, um das oben stehende Beispiel zu vervollständigen. Die bereits verwendete Sequenz (X, Y, Z) gibt an, dass ein X-Element von einem Y-Element gefolgt wird, welches wiederum von einem Z-Element gefolgt wird, wie in dem oben stehenden Beispiel zu ersehen ist. Ein weiterer bedeutender Zusammensetzungsoperator ist die Auswahl (X | Y | Z), welche eine Auswahl zwischen einem X-, einem Y-, oder einem Z-Element angibt. Andere Operatoren wären die Operatoren + und *, welche Wiederholungen einer Komponente angeben. Allerdings werden sie in den Beispielen nicht verwendet.
Angenommen, dass Y und Z keine Zusammensetzung (<!ELEMENT Y >, <!ELEMENT Z >) aufweisen, wird die DTD A mit Definition von X vervollständigt, wo die Zusammensetzung durch Auswahl und Rekursion auf Element A verwendet wird: <!ELEMENT X (Y | A)>.
Somit ist X entweder ein Y oder ein A. Mögliche Dokumente von Typ A sind nun:
und beliebige weitere Wiederholungen von <Y></Y>. Zur Vereinfachung wurden für Wiederholungen oben keine besonderen Zusammensetzungsoperatorenwie + und * verwendet. Als Abkürzung kann <Y> </Y> durch <Y/> ersetzt werden.
XML ist das Ergebnis eines langen Normungsprozesses und wird vielerorts verwendet und akzeptiert. Im Stand der Technik bestehende Anwendungen können in zwei verschiedene Grundtypen eingeteilt werden: Datenaustausch und Dokumentveröffentlichung. Für Datenaustauschanwendungen kann XML verwendet werden, um Datenformate zum Austauschen komplexer Daten zwischen zwei Programmen zu definieren. Ferner wird XML als Austauschformat für Daten verwendet, welche in relationalen Datenbanksystemen liegen. Beispiele für derartige Formate sind XML-Daten (Microsoft), MCF (Netscape) und RDF (W3C). Für Dokumentveröffentlichungsanwendungen ist XML die ideale Datensprache für die Auszeichnung aller Arten von Dokumenten. Der Hauptgedanke ist, den logischen Inhalt des Dokuments als XML-Dokument anzugeben und die Layoutinformationen generisch für die DTDs anzugeben. Beispiele für derartige generische Layoutsprachen sind CSS oder XSL. Die Ausgabe des generierten Layouts kann jeweils HTTP, SPDL oder Postscript sein.
XML-Verarbeitung
Derzeit verfügbare Software und Anwendungen bedienen sich XML zur Darstellung von Daten und Dokumenten, welche dann durch Allzweckprogrammiersprachen verarbeitet werden. Bestehende Vorschläge für das Verarbeiten von XML-Dokumenten können in ereignisgesteuerte und baumbedienende Methoden getrennt werden, unabhängig davon, ob die Anwendung im Datenaustausch- oder Dokumentveröffentlichungsbereich liegt. Bei einer ereignisgesteuerten Methode wird das Dokument in strikter Abfolge verarbeitet. Jedes Element im Datenstrom wird als Ereignisauslöser betrachtet, welcher eine besondere Handlung seitens der Anwendung auslösen kann. Das SAX Application Programmer Interface (API) kann verwendet werden, um eine ereignisgesteuerte Lösung in einer bestehenden Programmiersprache zu implementieren. Die Baum-Lösung bietet Zugriff auf das gesamte Dokument in Form eines Strukturbaumes. Im Grunde genommen sind die Elemente eines XML-Dokuments die Knoten des Baums, und die Komponenten jedes Elements sind die Geschwister des Knotens. Das gemeinhin verwendete API, um auf einen derartigen Baum zuzugreifen, ist DOM. Der Nachteil des Verwendens von APIs ist, dass die gesamte Komplexität des Allzweckprogrammierens, insbesondere System- und Plattformabhängigkeiten, Zuverlässigkeit und Sicherheit, welche zu umfangreicher und komplexer Software führen, ins Spiel kommt. Mehrere XML-Tools versuchen, diese Komplexität durch Generieren eines speziellen Codes für Datenaustausch- oder Dokumentveröffentlichungsanwendungen zu verbergen. Wenngleich sie eventuell dazu beitragen, ein Programmmuster in einer herkömmlichen Programmiersprache einfach zu generieren, abstrahieren sie nicht völlig von der Verwendung expliziter Programmierung, um durch das Dokument zu navigieren, welches verarbeitet werden muss.
Das Dokument CIANCARINI P ET AL: 'An extensible rendering engine for XML and HTML' COMPUTER NETWORKS AND ISDN SYSTEMS, NL, NORTH HOLLAND PUBLISHING. AMSTERDAM, Bd. 30, Nr. 1–7, 1. April 1998 (1998–04–01), S. 225–237, XP004121424 ISSN: 0169–7552, offenbart eine Java-Rendering-Maschine für XML-Daten. Ein Display Manager Applet ladet und parst das anzuzeigende Dokument. Der resultierende Baum wird dann rekursiv analysiert. Die Rendering-Maschine, welche von dem Display Manager Applet verwendet wird, ist ein Satz von Java-Klassen, welche das Rendering für die jeweiligen Dokumentelemente vorsehen. Das gemeinhin verwendete API, um auf einen derartigen Baum zuzugreifen, ist DOM.
XML gegenüber herkömmlichem Programmieren
Ein wichtiger Themenpunkt betrifft das Konzept von herkömmlich strukturierten sowie objektorientierten Programmierverfahren. Beide Verfahren bedienen sich unstrukturierter Datenquellen insofern, als die Struktur derartiger Daten nicht mittels Produktionsregeln angegeben wird, wie die Elementdefinitionen in XML- oder BNF-Regeln, welche die Struktur von Programmen definieren. Derartige Datenquellen werden, im Fall von herkömmlichem Programmieren, in Verbindung mit einem strukturierten, wenngleich unabhängigen Programm verwendet. Andererseits kombinieren objektorientierte Programmierverfahren den strukturierten, segmentierten Code mit Datenobjekten, wobei jedoch der Objektraum (Daten) noch nicht im oben angeführten Sinn strukturiert ist. Es wäre natürlich möglich, strukturierte Datenmodelle in Verbindung mit diesen Verfahren zu verwenden, jedoch ist in jedem der beiden Fälle die Programmstruktur von der Datenstruktur unabhängig und erfordert daher komplexe Behandlung, wie oben beschrieben wurde. Tatsächlich impliziert die aktuelle Situation beim Verarbeiten von XML-Dokumenten zwei unabhängige Strukturen, eine des XML-Dokumentes und eine des Programms, welches dieses verarbeitet. Diese Lösung ist insbesondere mit zwei grundlegenden Nachteilen behaftet: (a) Wenn ein Programmierer beabsichtigt, die gesamte Struktur einer beliebigen Instanz einer DTD zuverlässig zu verarbeiten, könnte ein derartiger Code infolge der Vielfalt entsprechender XML-Dokumente und der Komplexität derartiger Aufgaben versagen, und (b) das Programm, welches das XML-Dokument verarbeitet, ist für gewöhnlich ausgebildet, um alle Dokumente einer bestimmten DTD zu verarbeiten, wodurch die Komplexität des Programms durch das inhärente generische Wesen des Codes erhöht wird.
Aufgaben der Erfindung
Eine Aufgabe der Erfindung ist es, ein Verfahren, ein System und eine Vorrichtung bereitzustellen, um die Verarbeitung von XML-Dokumenten derart zu verbessern, dass Daten und Software in einer integrierten Struktur eingebunden werden, wodurch die Komplexität und/oder die Notwendigkeit grundlegender Programmierkenntnisse bei der Datenverarbeitung reduziert oder vermieden werden, und um die bestehende Struktur des XML-Dokuments wiederzuverwenden.
Eine andere Aufgabe der Erfindung ist, ein neues und allgemeines Verfahren, System und eine neue und allgemeine Vorrichtung bereitzustellen, um derartige integrierte Daten- und Softwarestrukturen für XML-Dokumente zu generieren. Noch eine andere Aufgabe der Erfindung ist, ein neuartiges Verfahren, System und eine neuartige Vorrichtung bereitzustellen, um Standarddokumentstrukturen, d.h. XML-Dokumente, direkt auszuführen.
Kurzdarstellung der Erfindung
Diese Aufgaben werden durch die Erfindung, wie sie in den Ansprüchen 1 und 7–9 dargelegt wird, realisiert.
Der Erfindungsgedanke beruht auf einem neuen Verfahren/System, welches sich ausführbarer Software und Daten in einer koordinierten und integrierten Struktur bedient. Die vorliegende Erfindung kann als eine Anwendung betrachtet werden, fällt jedoch in keine der oben genannten Kategorien, d.h. Datenaustauschanwendungen oder Dokumentveröffentlichungsanwendungen. Im Gegensatz zu derartigen bestehenden Anwendungen stellt diese Erfindung ein Verfahren und eine Vorrichtung bereit, um ein XML-Dokument direkt auszuführen (oder auf andere Weise zu verarbeiten).
Die vorliegende Erfindung verwendet die bestehende Struktur des XML-Dokuments wieder, wobei sie eine neue Struktur und ein neues Konzept für das Programm vermeidet, welches das Dokument verarbeiten sollte. Demzufolge definiert die erfinderische Lösung ein Programm für jedes Dokument (in Gegensatz zu einem für jede DTD), und somit wird die Prozesskomplexität deutlich reduziert.
Eine derartige Fähigkeit der direkten Ausführung von XML-Dokumenten wird mittels Dekorierens eines bestimmten XML-Dokuments und/oder seiner Dokumenttypdefinitionen (DTD) mit ausführbaren Befehlen, welche das lokale Verhalten und den lokalen Prozess jeweils für jeden Tag oder an jedem Knoten definieren, erreicht.
Dies wird durch Einbinden der Programmbefehle in Textform und/oder Grafikdiagramme, die sequenzielle oder gleichzeitige Steuerung und Datenfluss angeben, erreicht. Insbesondere erfolgt dies derart, dass die Instanziierung von Befehlen eines XML-Roboters auf ein spezifisches XML-Dokument angewandt wird, was ein ausführbares XML-Dokument ergibt, welches das gesamte Ausführungsverhalten des XML-Dokuments enthält.
Eine bevorzugte Ausführungsform der Erfindung bedient sich einer eindeutigen und allgemeinen DTD, welche die Modulstruktur, die für Module des XML-Roboters zu verwenden ist, spezifiziert. Ein spezifisches XML-Dokument kann durch Anwenden von Prozeduren und Spezifikationen, welche in einem derartigen XML-Roboter angegeben werden, auf das XML-Dokument verarbeitet werden. Daher sind die Module in die Struktur des XML-Dokuments derart eingebunden, dass die Ausführung des XML-Dokuments direkt durchgeführt wird. Die Ausführung baut auf einigen Funktionen (Primitives) auf, welche definieren, wie auf ein bestimmtes XML-Dokument zugegriffen und wie dieses geändert werden kann. Ferner definiert ein spezifisches und eindeutiges Flussdiagramm den Ausführungsprozess des XML-Dokuments in seiner Gänze. Diese grundlegenden Definitionen der Erfindung sind vollständig in dem Sinne, dass die angegebenen Beispiele für XML-Roboter zur direkten Ausführung gemäß der Erfindung führen.
Eine andere bevorzugte Ausführungsform der Erfindung stellt die gesamten Informationen für jede Art von Elementen eines bestimmten XML-Dokuments mittels eines grafischen Flussdiagrammes (GFC) bereit. Dieses GFC definiert den Steuerungsablauf durch die Elemente bzw. Komponenten und definiert, welche Aktionen während dieses Steuerungsablaufes ausgeführt werden. Der Datenfluss wird durch Aktionen bereitgestellt, welche ausgeführt werden, wenn bestimmte Zustände des GFC erreicht werden. Beispiele für GFCs sind Flussdiagramme, endliche Zustandsautomaten, Zustandsdiagramme, UML-Zustandsautomaten, alle Arten von Petri-Netzen, UML-Aktionsdiagramme und andere Arten von Rechenmodellen. Durch Darstellen des XML-Dokuments als Strukturbaum kann diese Ausführungsform auf rein grafische Weise definiert und erläutert werden, was eine fortgeschrittene visuelle integrierte Entwicklungsumgebung für XML-Roboter ermöglicht. Andererseits kann für sequenzielle GFC-Modelle (Flussdiagramme, endliche Zustandsautomaten), die Aktionen bezüglich Zuständen ausführen, diese grafische Ausführungsform direkt in eine Ausführungsform, die sich einer Textform bedient, umgesetzt werden. Zusätzlich könnte die Ausführungsform, welche sich einer Textdarstellung bedient, auf ein Modell verallgemeinert werden, welches Gleichzeitigkeit (d.h. die parallele Ausführung mehrerer Aktionen) und Aktionen hinsichtlich Pfeilen (d.h. Aktionen an Transitionen von endlichen Zustandsautomaten) ermöglicht, derart, dass alle Variationen dieser Ausführungsform in die Ausführungsform, welche sich grafischer Flussdiagramme bedient, umgesetzt werden könnten.
Beide Ausführungsformen sind durch eine modulare Struktur gekennzeichnet, wobei jedes Modul das Ausführungsverhalten für alle Elemente eines spezifischen Tag, z.B. <A ...>, definiert, wobei Ausführungsverhalten für Komponenten derartiger Elemente hinzugefügt wird und weiterhin Ausführungsverhalten für alle Instanzen von Elementen mit anderen Tags, z.B. <B...>, hinzugefügt wird. Alle Informationen in einem Modul, ob nun textliche oder grafische, beziehen sich auf eine Instanz der beschriebenen Art von Elementen (<A...>), die als self-Element bezeichnet wird. In beiden Ausführungsformen werden Primitives bereitgestellt, um externe Funktionen aufzurufen, durch die Struktur des Dokuments/Baums zu navigieren, über alle Instanzen einer bestimmten Art von Elementen (<A...>), und zusätzliche Attribute des Dokuments/Baums zu definieren, dessen Definition in einem rein funktionellen Stil angegeben ist. Wenn eine DTD für das auszuführende XML-Dokument vorliegt, liefert diese DTD explizit die Informationen darüber, welche Elementarten vorliegen und welche Komponenten für diese Arten vorhanden sind. Demnach bietet eine derartige DTD Struktur und Anleitung zum Schreiben einer XML-Roboterspezifikation. Wenngleich beide Ausführungsformen ohne eine explizite DTD arbeiten, wird eine DTD für die Definitionen und die Spezifikation der unten beschriebenen ersten Ausführungsform verwendet. Ferner muss festgehalten werden, dass eine einfache DTD von einem XML-Dokument ohne DTD abgeleitet werden kann.
In den bevorzugten Ausführungsformen werden Zwischenergebnisse durch dynamisches Erstellen und Neudefinieren von Attributen der Elemente in dem Dokument/den Knoten des Strukturbaums gespeichert. Andere rein funktionelle/deklarative Modelle auf Ereignisbasis sind ebenfalls möglich. Allerdings werden die dynamischen Prozessinformationen vorzugsweise durch die vorliegende Dokument/Baum-Struktur angegeben. Es ist wichtig zu verstehen, dass im Gegensatz zu bestehenden Verarbeitungsmodellen das Dokument oder der Strukturbaum des XML-Dokuments direkt als Basis für ein GFC (oder eine entsprechende Textform) verwendet wird, welches die Definition des Ausführungsverhaltens des XML-Dokuments ist. Demnach ist ein derartiger XML-Roboter eine grundlegende neue Möglichkeit des Anwendens der XML-Technik und des Verarbeitens von XML-Dokumenten.
Da die Erfindung nicht auf spezifische Plattformen oder konkrete Implementierungen des Prozesses, z.B. von bestehenden APIs wie SAX und DOM, beschränkt ist, muss die hier angegebene Spezifikation von derartigen konkreten Formen abstrahiert werden. Dennoch sind die verwendeten Primitives derart definiert, dass diese implementiert werden könnten. Ferner ist die Erfindung nicht auf spezifische Programmiersprachen beschränkt, welche das Flussdiagramm oder andere strukturelle Implementationen, beispielsweise ob Zwischenformen/-ergebnisse generiert werden oder ob das XML-Dokument mittels eines Compilers bzw. eines Interpreters oder einer Kombination daraus ausgeführt wird, implementieren.
Kurze Beschreibung von Ausführungsformen mit Bezugnahme auf die folgenden Zeichnungen
1 zeigt ein Beispiel für eine DTD namens "query".
2 zeigt ein XML-Dokument, das in Bezug auf die Beispiel-DTD gemäß 1 gültig ist.
3 zeigt die Baumstruktur des XML-Dokuments aus 2, welche durch die DTD "query" aus 1 impliziert wird.
4 zeigt eine grafische Spezifikation und deren entsprechende Instanziierung der DTD gemäß 1.
5 zeigt ein Spezifikationsmodul, das die Informationen der linken Seite von 4 für die Elementdefinition "query" einkapselt.
6 zeigt die Spezifikationsmodule für "setpoints" und "action" des Elements.
7 zeigt, wie die lokalen GFCs von jeder Elementdefinition für jede Instanz eines derartigen Elements im Strukturbaum instanziiert werden.
8 zeigt, wie die Instanzen der lokalen GFCs mit einem globalen, hierarchischen GFC verbunden sind.
9 zeigt die eindeutige DTD, welche die Modulstrukturen definiert.
10–15 zeigen die Flussdiagramme, welche die Ausführung eines bestimmten XML-Dokuments mittels Modulen, die in Bezug auf die DTD XML-robot.dtd gültig sind, definieren.
16–18 zeigen die Textdarstellung von Modulen des Beispiels gemäß 1 ff.
19a–19d zeigen Beispiele, wie eine spezifische XML-Roboter-Spezifikation implementiert werden kann.
20 zeigt eine Übersicht über eine Ausführungsform für eine XML-Roboterbeschreibung auf Web-Basis der bevorzugten Ausführungsform.
Bevorzugte Ausführungsformen der Erfindung werden in der Folge mit Bezugnahme auf die Zeichnungen beschrieben.
Die Erfindung realisiert die direkte Ausführung eines XML-Dokuments. Die folgenden Ausführungsformen beschreiben eine grafische und eine textliche Realisierung des Verfahrens, des Systems und der Vorrichtung. Wenngleich sich die nachfolgenden Beispiele auf XML-Dokumente einer bestimmten und bekannten DTD beziehen, versteht es sich, dass die Erfindung unter Berücksichtigung bestimmter Nachteile, beispielsweise undefinierte Resultate, die Ausführung von XML-Dokumenten ohne im vorhinein bekannte DTDs gestattet. In jedem Fall wird die DTD (falls im vorhinein bekannt) oder das XML-Dokument direkt mit der XML-Roboterspezifikation("Dekoration" der DTD oder des XML-Dokuments) integriert. Die Erfindung ist, wie oben beschrieben wurde, im Grunde genommen von der konkreten Implementierung (Plattform, Programmsprachen und strukturelle Formen wie Speichern und Verarbeiten) unabhängig. Allerdings werden nachstehend gegebenenfalls bevorzugte Ausführungsformen, die sich einer spezifischen Implementierung bedienen, beschrieben.
Bezugnehmend auf 1 bis 8 wird eine erste, grafische Ausführungsform der Erfindung beschrieben.
1 zeigt eine Beispiel-DTD mit einem Element "query", welches drei Komponenten, zwei vom Action-Typ und eine optionale Komponente vom Query-Typ, aufweist. Die Attributliste des Elements "query" besteht aus dem einen Attribut "question", wobei dieses ein erforderliches Zeichendatenattribut ist. Das Element "action" setzt sich entweder aus dem Element "setpoints" oder dem Element "query" zusammen. Das Element "setpoints" weist keine Komponenten und das einfache Attribut "points" auf.
2 stellt ein gültiges Dokument in Bezug auf die Beispiel-DTD aus 1 dar, wobei es auf die DTD "query.dtd" gemäß 1 verweist. Diese Instanz wird als Beispieldokument für die nachstehende weitere Beschreibung verwendet.
3 zeigt ein entsprechendes mögliches Umsetzen des Dokuments in 2 auf einen attributierten Strukturbaum (AST). Ein derartiger AST ist eine alternative grafische Darstellung der Struktur eines XML-Dokuments. Die Knoten, welche mit 1 und 3 nummeriert sind, sind Instanzen des Elements "query". Sie weisen die beiden erforderlichen "action"-Geschwister auf, die als "S1-action" und "S2-action" zugänglich sind, und der optionale "query"-Geschwister ist nicht vorhanden. Wenn ein "query"-Geschwister vorhanden wäre, wäre es als "S-query" zugänglich. Die Knoten 2, 4 und 5 sind Instanzen des Elements "setpoints", welche keine Geschwister aufweisen. Attribute und deren Werte werden innerhalb der Kästchen visualisiert.
4 zeigt die Relation der Ausführungsspezifikation für eine DTD und wie Instanzen der DTD ausgeführt werden. Die Spezifikation besteht aus der reinen DTD-Definition und aus vorzugsweise grafischen Flussdiagrammen (GFC) und Aktionen, die ausgelöst werden, wenn bestimmte Zustände der Diagramme erreicht werden. Das Kästchen auf der linken Seite stellt eine Ausführungsspezifikation für eine DTD dar, welche strukturiert ist in die reinen DTD-Komponenten, die Definitionen (visuelle Beschreibung) von grafischen Flussdiagrammen (GFC) und in Transitionsregeln. Letztere werden ausgelöst, während die Steuerung durch die Diagramme fließt. Als Alternative können dieselben Spezifikationen für die Elementinstanzen eines XML-Dokuments ohne DTD angegeben werden.
Das Kästchen auf der rechten Seite veranschaulicht, wie diese Struktur die direkte Ausführung eines XML-Dokuments impliziert. Die DTD, falls vorhanden, wird verwendet, um das XML-Dokument zu validieren. Ein attributierter Strukturbaum (AST) wird konstruiert. Die GFCs werden verwendet, um den AST zu dekorieren, was ein globales Flussdiagramm ergibt, das dem geparsten XML-Dokument entspricht. Das Dokument wird durch Ausführen des GFC, z.B. Auslösen der Aktionen, die bestimmten Zuständen der GFC zugeordnet sind, und Verarbeiten des Steuerungsablaufes gemäß den Bedingungen innerhalb der GFCs, ausgeführt.
Eine gesamte Ausführungsspezifikation ist in Spezifikationsmodule strukturiert. Jedes Spezifikationsmodul entspricht einer Elementdeklaration, welche das Ausführungsverhalten jenes Elements gemeinsam mit den zusätzlichen Ausführungsverhalten für die Komponenten jenes Elements und für die Instanzen anderer Elementarten beschreibt.
5 zeigt ein Beispiel dafür, wie ein Spezifikationsmodul für das Element "query" gemäß 1 aussieht. Der oberste Teil des Spezifikationsmoduls enthält relevante Element- und Attributdefinitionen. Der mittlere Teil gibt ein GFC-Fragment an, welches das Ausführungsverhalten für Instanzen des Elements "query" spezifiziert. Das GFC-Fragment wird mittels des bevorzugten Verfahrens einer grafischen Darstellung angegeben. Schließlich wird im unteren Teil von 5 die Transitionsregel dargestellt.
Bezugnehmend auf 4 und 5 wird nun das bevorzugte Verfahren des Verwendens einer grafischen Darstellung der Beispiel-DTD aus 1 ausführlicher beschrieben. Das gezeigte Beispiel stellt eine GFC mit einer sequenziellen Steuerung, vergleichbar mit endlichen Zustandsautomaten, Zustandsdiagrammen, klassischen Flussdiagrammen oder UML-Zustandsautomaten, dar. Die Prozedur funktioniert auf ähnliche Weise für verteilte GFCs wie Varianten von Petri-Netzen oder UML-Aktivitätsdiagrammen. Bei dieser Ausführungsform wird das Ausführungsverhalten eines XML-Dokuments mittels eines sequenziellen grafischen Flussdiagramms angegeben, dessen Zustände Aktionen zugeordnet sind. Bei alternativen Ausführungsformen können Pfeile des GFC Aktionen zugeordnet sein. Beim vorliegenden Ausführungsbeispiel werden in jedem beliebigen Zustand des GFC die entsprechenden Aktionen ausgelöst, gefolgt von einer Zustandstransition zum nächsten Zustand. Wie bei anderen Formalismen auf Zustandsbasis (beispielsweise Harelschen Zustandsdiagrammen) können bei dem vorliegenden GFC die Ablaufpfeile mit booleschen Prädikaten gekennzeichnet werden, welche den Fluss der Steuerung bestimmen, wobei Labels weggelassen werden können. Ein Ablaufpfeil ohne einen Label weist ein Standardverhalten auf, z.B. wenn kein anderer Pfeil, der von seiner Quelle ausgeht, einen Label aufweist, der bei Auswertung wahr ergibt, dann wird der nicht mit einem Label versehene Pfeil aktiv.
Wie auf der linken Seite von 4 dargestellt ist, besteht eine Verhaltensspezifikation einer DTD aus drei Teilen: der DTD-Definition selbst, einer visuellen Notation zum Spezifizieren der GFCs und der Spezifikation der Aktionen. Darüber hinaus kann eine Spezifikation zur Berechnung von zusätzlichen Attributen vor der Ausführung, vorzugsweise angegeben durch funktionelle Abhängigkeiten und Sicherheitsbedingungen, welche von den Attributen abhängen, die durch die DTD und durch die Spezifikation von zusätzlichen abgeleiteten Attributen abhängig sind, vorliegen. Die DTD wird verwendet, um einen Parser zu generieren, und dann wird ein geparstes XML-Dokument auf kanonische Weise in einen AST umgesetzt. Der zweite Teil einer Spezifikation beschreibt den Steuerungsablauf im Sinne von Zustandstransitionen in einem GFC. Eine visuelle Beschreibung ist jeder Elementdeklaration der DTD zugeordnet und definiert ein lokales GFC und spezifiziert auch, wie dieses GFC über eine induktive Dekoration des AST in ein globales GFC eingefügt werden kann. Zu diesem Zweck ist jeder Knoten des AST mit einer Kopie des GFC-Fragments dekoriert, das durch seine grafische Darstellung angegeben ist. Die Verweise auf Abkömmlinge eines Knotens definieren eine induktive Konstruktion des globalen GFC, wie unten in Zusammenhang mit seiner Ausführung (vgl. 7 und 8) beschrieben wird. Der letzte Teil besteht schließlich aus Transitionsregeln, welche die Aktionen spezifizieren, die während der Ausführung des Dokuments ausgelöst werden. Jeder Zustand des GFC kann einer Transitionsregel zugeordnet sein, welche ausgelöst wird, wenn dieser Zustand erreicht wird. Die Transitionen in dem GFC sind bedingt, wobei die Bedingungen aus Attributen der Knoten des AST aufgebaut werden.
Das GFC in 5 enthält einen runden Knoten, welcher einen Zustand namens „ask" darstellt. Wenn dieser Zustand erreicht wird, wird die entsprechende Aktion im untersten Teil des Moduls ausgelöst. Dann läuft die Steuerung entweder zu dem mit "S1-action" gekennzeichneten Kästchen oder zu dem mit "S2-action" gekennzeichneten Kästchen weiter, je nach den Bedingungen, mit welchen die Ablaufpfeile beschriftet sind. Die Kästchen stellen die GFCs dar, welche den Geschwistern entsprechen, auf die über ihre Labels verwiesen wird. Die Pfeile I und T stellen den Eintritts- bzw. den Austrittspunkt des Steuerungsablaufes dar.
In der ersten Ausführungsform werden, wie später beschrieben wird, I und T wie normale Zustände behandelt, die als "initial" und "terminal" bezeichnet werden. Die Pfeile von I weg und zu T hin müssen explizit als Transitionen von "initial" weg und zu "terminal" hin angegeben werden. Weitere Pfeile in Kästchen hinein müssen explizit als Pfeile zum "initial"-Zustand des Kästchens angegeben werden, und Pfeile aus Kästchen heraus müssen als Pfeile vom "terminal"-Zustand des Kästchens weg angegeben werden. Diese Entsprechung ist unten in Zusammenhang mit 1 bis 8, welche die GFC in Textform darstellen, einfach zu verstehen.
6 zeigt die Spezifikationsmodule "action" und "setpoints" der Beispiel-DTD aus 1. Während "action" lediglich die Wahl zwischen "setpoint" und "query" ist und somit die GFC-Definitionen dieser Elementdefinitionen übernimmt, führt Elementmodul setpoint eine triviale GFC ein, welche aus einem Zustand besteht, dessen entsprechende Aktion das Erhöhen des Werts eines PointCounter um die Zahl ist, welche mittels des Attributs "points" angegeben wird.
Wie festgehalten wurde, enthält die visuelle Notation in jedem Spezifikationsmodul die Informationen über das lokale GFC, welche jedem Knoten des AST, der dem Spezifikationsmodul entspricht, zuzuordnen ist, und die Informationen, die erforderlich sind, um dieses GFC in das globale GFC, welches dem eingegebenen Dokument entspricht, einzubetten.
7 zeigt, wie die grafischen Fragmente von jeder der grafischen Darstellungen den Knoten des AST, welche dem Beispieldokument entsprechen, zugeordnet werden, und veranschaulicht dadurch, wie ein globales GFC aus einem AST durch Übereinstimmen der GFCs gemäß 5 und 6 mit den entsprechenden Knoten des AST erhalten werden kann. Zu sehen sind zwei Instanzen des GFC-Fragments, welches durch das Modul "query" angegeben wird (vgl. 5), und drei Instanzen des trivialen GFC-Fragments, welches durch das Modul "setpoints" (vgl. 6) angegeben wird. Wiederum zeigt diese Figur die Dekoration jedes Knotens im AST, welche mittels einer grafischen Darstellung erreicht wird. Eine derartige grafische Dekoration kann den Steuerungsablauf auf bevorzugte Weise realisieren. Allerdings versteht es sich, dass sich die Erfindung Lösungen bedienen kann, bei denen textliche Programmbefehle oder andere Mittel den Steuerungsablauf und das Auslösen von Aktionen, welche hier mit den grafischen Flussdiagrammen realisiert werden, ersetzen würden.
8 zeigt das hierarchische GFC, welches aus einer induktiven Verschachtelung dieser Fragmente resultiert. Die GFC-Fragmente in 7 enthalten Kästchen mit Verweisen auf Geschwister. Die Verschachtelung erfolgt durch Auflösen dieser Verweise.
Ein eingehenderes Verstehen der hier verwendeten visuellen Notation für den Steuerungsablauf sollte durch die folgende Spezifikation vermittelt werden. Die Semantik der grafischen Notation, die in den Spezifikationsmodulenverwendet wird, kann beschrieben werden wie folgt:
Es gibt zwei Arten von Knoten: Ovale und Kästchen. Die Ovale stellen die gewöhnlichen Zustände des GFC dar. Sie sind auch mit einem Aktionsnamen beschriftet, wobei die Aktion (welche mittels Transitionsregeln spezifiziert ist) ausgelöst wird, wenn der Zustand erreicht wird. Die Kästchen entsprechen Überzuständen, welche ihrerseits GFCs sind. Darüber hinaus entsprechen die Kästchen den Knoten des AST. Diese direkte Eins-zu-Eins-Entsprechung von Überzuständen im GFC und Knoten im AST ist die detaillierte Ausführungsform der Kennzeichnung der Struktur des AST und der Struktur des Ausführungsverhaltens. Natürlich ist die beschriebene Verwendung von Kästchen, der Verweis dieser auf Komponenten und die Eins-zu-Eins-Entsprechung der Strukturen von der spezifischen Form von GFC, von Ablaufbedingungen und von Aktionen unabhängig.
Die Kästchen sind das GFC, welches den Komponenten auf der rechten Seite der Elementdefinition entspricht. Die Definition dieser GFCs wird im Spezifikationsmodul,welches den jeweiligen Elementen entspricht, angegeben. Die Pfeile entsprechen Kanten im hierarchischen Zustandstransitionsgraph des generierten GFC. Die Quelle und das Ziel eines Pfeils können entweder ein Kästchen oder ein Oval sein. Darüber hinaus liegen zwei Pfeile vor, einer dessen Quelle mit I (für "initial") gekennzeichnet und dessen Ziel ein Kästchen oder ein Oval ist und der andere dessen Ziel mit T (für "terminal") gekennzeichnet und dessen Quelle ein Kästchen oder ein Oval ist. Der mit I gekennzeichnete Pfeil zeigt den Eintrittspunkt in das lokale GFC an, und der mit T gekennzeichnete zeigt den Austritt davon an. Eine Transition zu einem Überzustand des GFC resultiert in einem Eintritt zu dem ersten Zustand des GFC (durch den I-Pfeil gekennzeichnet), welcher diesen Überzustand darstellt. Die Kästchen in der visuellen Beschreibung in jedem Spezifikationsmodul sind Verweise auf das entsprechende GFC. Das Auflösen dieser Verweise für das dekorierte Beispieldokument, welches in 7 beschrieben ist, führt zu dem in 8 dargestellten GFC. Dieses generierte hierarchische GFC gibt das Ausführungsverhalten des XML-Dokuments an, und eine direkte Ausführung des hierarchischen GFC ist möglich, was ermöglicht, XML-Dokumente direkt auszuführen. Die Fähigkeit, die XML-Dokumente direkt auszuführen, hängt nicht von der spezifischen Art von GFC ab, welche in der bevorzugten Ausführungsform dargestellt ist, und jedwede Form von GFC, welche direkt ausgeführt werden kann, ist geeignet.
In der beispielhaften Form von GFC, wie bei Zustandsdiagrammen, erfolgt ein Eintritt in einen hierarchischen Zustand am Initialzustand, welcher durch einen Pfeil I angezeigt wird. Wenn der Endzustand (durch einen wegführenden Pfeil T gekennzeichnet) erreicht wird, erfolgt eine Transition zu einem Zustand, welcher in der Hierarchie eine Ebene höher liegt.
Demnach funktioniert die Ausführung des hierarchischen GFC in 8 wie folgt. Die Steuerung tritt bei der Wurzel des Strukturbaumes, d.h. Knoten 1, ein. Der Initialzustand des entsprechenden GFC ist der "ask"-Zustand innerhalb des Knotens 1. Das Attribut "question" dieses Knotens ist "Ist Paris die Hauptstadt von Frankreich?" Nach dem Auslösen der "ask"-Aktion, sollte das Attribut "answer" entweder auf "yes" oder "no" gesetzt werden. Wenn die Antwort gleich "yes" ist, folgt die Steuerung dem oberen Ablaufpfeil, der den "ask"-Zustand verlässt, und tritt bei Überzustand 2 ein. Der Initial- und der Terminal-Zustand von Überzustand 2 ist die Aktion "set". Nach dem Ausführen der Aktion "set" und dem Verlassen von Überzustand 2, geht es weiter zum (optionalen und im Wirklichkeit nicht existierenden) "S-query"-Geschwister, wobei keinerlei Aktion ausgelöst wird, und der Überzustand 1 wird verlassen. Wenn die Antwort auf die Frage im "ask"-Zustand von Überzustand 1 "no" war, erfolgt ein Eintritt in Überzustand 3, und von dort geht es weiter zum Initialzustand "ask" von Überzustand 3. Diesmal wird die Frage "Sind Sie sich sicher?" gestellt. Wenn die Antwort ein insistierendes "yes" ist, wird der PointCounter um 0 erhöht, andernfalls um 1 (Überzustände 4 und 5).
Bei einer bevorzugten Ausführungsform der Erfindung werden die Zustände mittels Datenwürfeln gehandhabt. Die Transitionsregeln für die Aktionen definieren den Inhalt derartiger Datenwürfel punktweise neu. Dies mag durch Annahme eines vereinfachten Modells eines imperativen Programmiersystems besser zu verstehen sein. Der Zustand des Systems wird durch eine mehrdimensionale Datenbank angegeben. Die Datenbank besteht aus n-dimensionalen Würfeln. Der Inhalt eines n-dimensionalen Würfels f kann durch den folgenden Term f (t₁,..., t_n ) gelesen werden, wobei t₁,.., t_n Terme sind, welche über den Würfeln der Datenbank gebaut sind. Eine normale Variable entspricht einem 0-dimensionalen Würfel, wohingegen Arrays und Records mit 1-dimensionalen Würfeln modelliert werden können.
Die möglichen Werte, welche in Würfeln gespeichert sind, können die üblichen Datentypen wie ganze Zahlen, reelle Zahlen, boolesche Werte oder beliebige andere, die in einer spezifischen Anwendung erforderlich sind, beispielsweise die Knoten eines Strukturbaums oder dynamisch generierte Objekte, umspannen. Attribute der Knoten des Strukturbaumes werden durch eindimensionale Würfel modelliert, und der Wert eines Attributs a eines Knotens n kann durch den Term a(n) erhalten werden. Aus Gründen der Zweckmäßigkeit wird die Punktnotation, welche in Attributgrammatiken und objektorientierter Programmierung verwendet wird, z.B. n.a anstatt a(n), ebenfalls verwendet.
Beispielsweise ist eine grundlegende Aktualisierungsregel von der Form f (t₁,..., t_n) :=v, wobei f (t₁,..., t_n) und v Terme sind, welche über den Würfeln in dem System gebaut sind. Die Semantik einer derartigen Regel ist, den Würfel f an der Position von bestimmten Koordinaten auf v zu aktualisieren. Die Regeln können entweder sequenziell oder auf parallele Weise, so dass die entsprechenden Aktualisierungen alle gleichzeitig ausgeführt werden, zusammengesetzt sein. Neben der oben dargestellten grundlegenden Transitionsregel können auch andere Transitionsregeln existieren, beispielsweise bedingte Regeln, bei denen das Auslösen von dem ausgewerteten booleschen Bedingungs-Term abhängt, Do-For-All-Regeln, welche das Auslösen derselben Regel für alle Elemente einer bestimmten Art ermöglichen, Auswahlregeln, welche das Auswählen eines Elements von einer bestimmten Art ermöglichen, und schließlich Ausweitungsregeln, welche für das Einführen neuer Elemente verwendet werden. Transitionsregeln werden rekursiv aus diesen Regeln aufgebaut.
Der Prozess des Ausführens der Transitionsregeln wird nunmehr ausführlicher beschrieben, immer noch mit Bezugnahme auf 8. Es ist möglich, die Ausführung des Beispielprogramms durch Verwendung der Aktionsregeln, die in den grafischen Darstellungen in 5 und 6 angegeben werden, nachzuverfolgen. Der Initial-Zustand ist ein einfacher Zustand, welcher mit der Aktion "ask" gekennzeichnet ist, wobei der Eintritt in diesen Zustand durch den I-Pfeil im grafischen Fragment gekennzeichnet ist, welches am Wurzelknoten des AST befestigt ist. Die Aktion "ask", die im "query"-Modul spezifiziert ist, wurde oben beschrieben (vgl. 3) und führt zum Drucken der Frage, die in dem Attribut "question: Ist Paris die Hauptstadt von Frankreich?" verfügbar ist. Dann wird eine Benutzereingabe erhalten (z.B. get(stdin)), und das Attribut "answer" wird auf die bereitgestellte Eingabe gesetzt.
Nachdem diese Aktionsregel ausgeführt wurde, werden die Bedingungen an den von diesem Zustand wegführenden Pfeilen ausgewertet. Zwei Pfeile führen von dem "ask"-Zustand weg, einer gekennzeichnet mit der Bedingung answer= " yes" und der andere mit der Bedingung answer= "no". Je nach dem Wert der Antwort, wird dem entsprechenden Pfeil gefolgt, der zum Überzustandknoten 2 oder zum Überzustandknoten 3 führt. Angenommen, die Antwort war "no", würde dem unteren Pfeil gefolgt werden und der Eintritt in den Überzustand 3 erfolgen. Da dies ein Überzustand ist, führt er zu einer Abfolge von Transitionen durch die Zustände des Flussdiagramms, welches diesen Überzustand darstellt. In diesem Fall ist der Initial-Zustand innerhalb dieses Überzustands wieder ein einfacher Zustand, der mit dem Oval dargestellt und wieder mit der Aktion "ask" gekennzeichnet ist. Diesmal wird die Frage "Sind Sie sich sicher?" gedruckt. Ja nach der Antwort des Benutzers folgt als nächstes entweder Knoten 4 oder Knoten 5. Diese Knoten sind Überzustände, welche einen einzigen Zustand enthalten, der durch die Aktion "set" gekennzeichnet ist. Diese Aktion fügt dem 0-dimensionalen Würfel soviele Punkte hinzu, wie mit dem Attribut "points" spezifiziert werden. Folglich erhält ein Benutzer, der auf die Initialfrage mit "yes" antwortet, 10 Punkte, ein Benutzer, der mit "no" antwortet und dann mit "yes" erhält 0 Punkte, und ein Benutzer, der auf die erste Frage mit "no" und auf die zweite mit "no" antwortet, erhält 1 Punkt. Infolge der Struktur des generierten GFC wird einem Benutzer, der auf die erste Frage mit "yes" antwortet, niemals die zweite Frage gestellt.
Abstrakter wird ein XML-Dokument demnach durch Generieren seines GFC, wie beschrieben wird, und darauffolgendes Beginnen mit dem Initial-Zustand (oder Initial-Zuständen im Fall gleichzeitiger Ausführung) seines Wurzelelements ausgeführt. Der Initial-Zustand wird durch Eintreten in den Überzustand, welcher der Wurzel des Dokuments entspricht, und Folgen des I-Pfeils gefunden. Wenn der I-Pfeil zu einem normalen Zustand führt, wird in diesen Zustand eingetreten, wobei andernfalls den I-Pfeilen rekursiv gefolgt wird. Wenn der Eintritt in den Initial-Zustand erfolgt, wird seine Aktion ausgelöst. Dann werden die Bedingungen auf den wegführenden Ablaufpfeilen ausgewertet, und ein Pfeil (oder mehrere Pfeile im gleichzeitigen Fall) mit erfüllter Bedingung wird ausgewählt. Wenn der Pfeil zu einem normalen Zustand führt, wird dieser Zustand ausgeführt, und die Prozedur wird wiederholt. Wenn der Pfeil zu einem Überzustand führt, wird den I-Pfeilen rekursiv gefolgt, um den nächsten auszuführenden Zustand zu bestimmen, und die Prozedur wird wiederholt. Wenn der Pfeil ein T-Pfeil ist, erfolgt ein Austritt aus dem Überzustand, und einer der wegführenden Pfeile des Überzustands mit erfüllter Bedingung wird ausgewählt. Diesem Pfeil wird wieder gefolgt, wie oben beschrieben wurde.
Demnach wird die Zusammensetzung der Aktion für eine XML-Elementdefinition entweder durch grafische und/oder textliche, sequenzielle oder gleichzeitige Steuerungsablauf- und/oder Datenflussdiagramme dargestellt. Spezielle textliche und/oder grafische Mittel werden bereitgestellt, um auf die Komponenten der XML-Elementdefinition zu verweisen, was die synchrone und/oder asynchrone Ausführung der Aktionen der Komponenten ermöglicht, derart, dass die Struktur des Dokuments, welche durch die Komponenten in jeder Elementdefinition angegeben wird, direkt in der Struktur der Ausführung, welche durch das Auslösen von Aktionen von Komponenten angegeben wird, wiederverwendet wird. Ferner können spezielle grafische und/oder textliche Mittel zum Definieren der sequenziellen oder gleichzeitigen Ausführungsreihenfolge der Aktionszusammensetzung gemeinsam mit Bedingungen bereitgestellt werden, welche bestimmte Ausführungspfade der spezifizierten Reihenfolge schützen. Diese speziellen grafischen und/oder textlichen Mittel können innerhalb der Definition von Bedingungen und Aktionen zum Verweisen auf den Knoten, für welchen die Aktionskombination definiert ist, zum Verweisen auf seine Komponenten und zum Verweisen auf seine Attribute, welche durch die XML-Attributdefinitionen angegeben werden, enthalten sein.
Bezugnehmend auf 9 bis 18 wird nun eine zweite, textliche Ausführungsform der Erfindung beschrieben.
9 zeigt die eindeutige allgemeine DTD für die XML-Robotermodule, welche das Ausführungsverhalten von XML-Dokumenten gemäß der Erfindung darstellen. In der Folge wird mit Bezugnahme auf 9 ff eine Ausführungsform, die sich einer textlichen Realisierung der Erfindung bedient, ausführlicher beschrieben. Um 9 ff. zu beschreiben, werden die erforderlichen Syntax- und Primitive-Funktionen zunächst nachstehend definiert und erläutert. Die folgenden Definitionen konzentrieren sich auf die textliche Realisierung (Realisierung auf Textbasis).
Ein auszuführendes XML-Dokument ist als "doc.xml" benannt, und der XML-Roboter wird durch Dokumente definiert, denen, wenn der Elementname X ist, die Dateinamen "moduleX.xml" gegeben wurden. Ferner wird angenommen, dass alle diese Dateien durch die Flussdiagramme, die in 10 ff. dargestellt werden und die Ausführung von doc.xml erläutern, frei geändert werden können. Der Zustand der Ausführung besteht aus den genannten Dokumenten und den Werten elf globaler Variablen, die hier als cur, mod, state, derived, subcur, submod, curstate, action, trans, src und trg bezeichnet werden. Die Ausführung ändert die angegebenen Dokumente durch Erstellen und Neudefinieren von Attributen und durch Einfügen der Zustandselemente der Module in das Dokument "doc.xml". Ferner werden die Werte der globalen Variablen während der Ausführung neudefiniert (aktualisiert). Wenn beispielsweise die Variable cur den Wert v1 aufweist, im aktuellen Zustand der Ausführung, führt die Ausführung der Aktualisierung cur := v2 zu einem neuen Zustand, in dem die Variable cur den Wert v2 aufweist. Bei den vorliegenden Definitionen sind die Werte der globalen Variablen Verweise innerhalb der XML-Dokumente oder die Konstante "undef".
Das zu verarbeitende XML-Dokument bedient sich der zuvor beschriebenen genormten Struktur und enthält Elemente mit Start- und End-Tags der Form <A ...> ... </A>. Verweise auf Elemente sind Zeiger innerhalb der Dokumente. Die Verweise könnten (a) mittels Textpositionen (welche auffordern, sie zu aktualisieren, wenn weiterer Text in das Dokument eingefügt wird), (b) bestehender Verweismechanismen in der XML-Linkdefinition, (c) Zeiger auf Objekte in einem Objektmodell von XML-Strukturbäumen, beispielsweise DOM, oder den in der Ausführungsform mittels GFC beschriebenen Bäumen, implementiert werden.
Zu Gunsten eines besseren Verstehens des Ausführungsprozesses kann nun unser Hauptaugenmerk auf die Attribute des Elements gerichtet werden. Als ein Beispiel wird das Attribut aa eines Elements A, welches beispielsweise einen Wert "13" aufweist, folgendermaßen angegeben: <A aa="13"> ... </A>. Um den Wert des Attributs zu lesen, wird eine Funktion evalAttr(_,_) bereitgestellt, welche zwei Argumente, einen Verweis auf ein Element und einen Attributnamen nimmt und den Wert des Attributs liefert. Angenommen doc.xml enthält das Element A und r ist ein Verweis auf dieses Element, dann ergibt der Term evalAttr(r, "aa") bei Auswertung "13". Die Syntax "r.evalAttr("aa")", welche äquivalent mit evalAttr(r, "aa") ist, und analoge Syntaxen für andere Aktionen, werden aus Gründen der Zweckmäßigkeit auch in den 10 ff. und der Beschreibung verwendet.
Die Ausführung des XML-Dokuments, welche in den folgenden Absätzen beschrieben wird, setzt voraus, dass die Attribute dynamisch aktualisiert und/oder erstellt werden. Daher wird eine Prozedur setAttr(_,_,_) bereitgestellt, welche drei Argumente nimmt: das erste ist ein Verweis auf ein Element, das zweite auf einen Attributnamen und das dritte der neue (Initial-)
Wert des zu aktualisierenden (erstellenden) Attributs. Z.B. wandelt die Aktion r.setAttr("aa", "15") das Dokument doc.xml derart um, dass das Element A, auf welches durch r verwiesen wird, die Form <A aa="15"> ... </A> erhält. Eine Aktion r.setAttr("bb", "7") würde das Dokument doc.xml derart umwandeln, dass das Element, auf welches durch r verwiesen wird, die Form <A aa="13" bb="7"> ... </A> aufweist. Wenn beide Aktionen in einer beliebigen von beiden Reihenfolgen ausgelöst werden, wird die resultierende Form des Elements, auf welches mittels r verwiesen wird, <A aa="15" bb="7"> ... </A>. Bei dieser Ausführungsform sind die Elemente, auf welche verwiesen wird, Teile eines physikalischen Dokuments, beispielsweise doc.xml, und die Umwandlung des Elements führt zu einer destruktiven, nicht umkehrbaren Änderung des XML-Dokuments.
Ferner können zusätzlich zu Standardwerten v, welche in XML existieren, beispielsweise Strings und Zahlen, Attribute auf Werte gesetzt werden, welche Verweise auf (andere) Elemente in Dokumenten sind, beispielsweise der Verweis r in den oben beschriebenen Beispielen. Wie erwähnt wurde, können derartige Verweise auf verschiedenerlei Weise implementiert werden, solange die Ausführung von Aktion r1.setAttr(a,v) bewirkt, dass der Term r1.evalAttr(a) bei Auswertung v ergibt, bis eine andere Aktion r1.setAttr(a, v') auf dasselbe Element r1 und dasselbe Attribut a, jedoch mit einem anderen Wert v' ausgelöst wird.
Eine Aktion "PasteInside" wird verwendet, um Text in ein XML-Dokument einzufügen. Die Aktion weist zwei Argumente auf, wobei das erste ein Verweis auf ein Element und das zweite der einzufügende Text ist. Der Text wird direkt nach dem Start-Tag des Elements, auf das verwiesen wird, eingefügt. Wieder in Anbetracht eines Verweises r wandelt die Aktion r.pastInside("textsample") das Element A, auf welches verwiesen wird, innerhalb doc.xml in die folgende Form: <A aa="13"> textsample ... </A> um.
Eine Aktion "Copy" wird verwendet, um einen String aus einem Verweis zu erstellen. Wieder in Anbetracht des oben angeführten Beispiels eines Verweises r, der auf ein Element A in doc.xml zeigt, ergibt der Term r.copy bei Auswertung den String "<A aa=13> ...</A>", welcher syntaktisch mit dem Element, auf das verwiesen wird, ident ist, jedoch physikalisch verschieden ist. Wenn ein Element kopiert wird, bleiben die Attribute des Elements gleich, der Verweis auf das kopierte Element bleibt jedoch derart, dass er nur auf das Dokument zeigt, von welchem die Kopie genommen wird.
Die Aktionen PasteInside und Copy werden verwendet, um Teile von einem in ein anderes Dokument zu kopieren. In Anbetracht von zwei Dokumenten
doc1.XML:
und Verweis r1, welcher auf das Element B von docl.XML zeigt, und r2, welcher auf das innere Element C von doc2.XML zeigt, führt die Aktion r1.pasteInside(r2.copy) zu einem umgeformten doc1.XML:

wohingegen doc2.XML unverändert bleibt. Attribute des Elements C, auf welches mittels r2 verwiesen wird, werden kopiert, Verweise in doc2.XML hinein werden jedoch nicht geändert.
In Anbetracht eines physikalischen Dokuments, z.B. die Datei doc.xml (oder eine der moduleXYZ.xml-Dateien), ergibt der Term getRef("doc.xml") bei Auswertung einen Verweis zur Wurzel des Dokuments, z.B. das äußerste Start/Ende-Tag-Paar. Ferner ergibt der Term r.getLabel bei Auswertung den Namen des Elements, auf welches durch r verwiesen wird. In den oben angeführten Beispielen mit doc1.XML und doc2.XML, ergibt r1.getLabel bei Auswertung "B" und r2.getLabel bei Auswertung "C".
Die Navigation durch XML-Dokumente erfolgt mittels der Funktionen getFirst(_,_), getNext(_) und parent(_). Das erste Argument aller drei Funktionen ist ein Verweis auf ein Element innerhalb eines XML-Dokuments. In Anbetracht eines Verweises r, ergibt r.getFirst("A") bei Auswertung einen Verweis auf das erste Element A direkt innerhalb der Start- und End-Tags von r. Verschachtelte Instanzen werden nicht berücksichtigt. In den Beispielen mit doc1.XML und doc2.XML kann der Verweis r1 mittels des Terms getRef("doc1.XML") erhalten werden, und der Verweis r2 kann mittels des Terms getRef("doc2.XML") erhalten werden.
Wenn kein Element mit dem angeforderten Namen vorliegt, ergibt getFirst bei Auswertung die Konstante "undef". Ferner verweist getRef nicht auf verschachtelte Elemente. Bezugnehmend auf die oben angeführten Beispiele ergibt getRef(doc1.XML).getFirst("A") bei Auswertung keinen Verweis auf das innere A-Element, sondern "undef". Um einen Verweis auf das innere A-Element zu erhalten, musste getRef(doc1.XML).getFirst("B").getFirst("A") verwendet werden.
Infolge der Definition von getFirst, entweder r.getFirst("l").getLabel = "l" oder r.getFirst("l") = undef, für jedweden Verweis r und Label "l".
Die Funktion getNext(_,_) liefert einen Verweis auf das nächste Element mit demselben Label, falls vorhanden, wobei andernfalls "undef" geliefert wird. In Anbetracht eines Verweises r auf das folgende XML-Fragment:
Der Verweis r.getFirst("B") verweist auf das B-Element mit x ="1", der Verweis r.getFirst("B").getNext verweist auf das B-Element mit x="2", der Verweis r.getFirst("B").getNext getNext verweist auf das B-Element mit x="4". Um auf das B-Element mit x="3" zu verweisen, ist es erforderlich, r.getFirst("B").getNext.getFirst("B") zu schreiben.
Die Funktion "parent" setzt einen Verweis auf ein Element in einen Verweis auf das wenigst einschließende Element um. In den Beispielen mit doc1.XML und doc2.XML gilt r1.parent = getRef("doc1.XML") und r2.parent.parent = getRef("doc2.XML").
Die Funktion "<CopyList(_,_)" verwendet als erstes Argument einen Verweis und als zweites Argument einen Elementnamen. r.CopyList(a) setzt einen String durch Verketten aller Elemente A direkt (nicht verschachtelt) in r zusammen. Demnach führt, in Anbetracht des Beispiels im oben stehenden Absatz über getNext, r.CopyList zu der String "<Bx="4">", die aus 3 B-Elementen besteht, wobei das zweite durch Zufall ein anderes, verschachteltes B-Element enthält.
Schließlich wird eine Funktion "traverse" vorgesehen. Beginnend mit einem Verweis auf die Wurzel, zählt "traverse" alle Elemente im Dokument in einer Reihenfolge auf.
Nun wird in 9 die DTD für die Module definiert. Die Elemente dieser DTD werden nachstehend schrittweise erläutert. Für gewöhnlich werden die Module in getrennten Modul-Dateien angegeben. Natürlich mussten die DTDs mit einem eindeutigen Wurzelelement vervollständigt werden. Allerdings könnte eine gesamte Sprache mit einer Liste aller Module in einer DTD enthalten sein. Das oberste Modul-Element ist die Wurzel dieser Modul-Dateien.
Die Komponenten eines Moduls sind eine Liste von abgeleiteten Attributen, ein optionaler Ausdruck, eine Liste von Zuständen und eine Liste von Modulen (Untermodulen). Das "name" -Attribut gibt das Element an, auf welches das Modul anwendbar ist. Die Definitionen beruhen auf der Annahme, dass ein Element "X" im auszuführenden Dokument vorliegt, dass ein XML-Dokument namens "moduleX.xml", dessen Wurzelelement ein "module"-Element ist, existiert, und dass das Wurzelelement ein "name"-Attribut mit dem Wert "X" aufweist.
Die Liste von abgeleiteten Attributen enthält Attributdefinitionen, welche nach funktionellen Abhängigkeiten von anderen Attributdefinitionen angegeben werden. Der optionale Ausdruck gibt eine Sicherheitsbedingung an, welche durch jede Instanz eines derartigen Elements erfüllt werden muss. Die Zustände sind die (nicht verschachtelten) Zustände jeder Instanz eines derartigen Elements. Schließlich bezieht sich die Liste von Modulen auf die Komponenten des Elements, wobei für jede dieser die Untermodule Zustände und weitere Untermodule enthalten können. Für die Untermodule bezeichnet das "number"-Attribut, auf welche Instanz es sich bezieht. Wenn es sich auf die erste Instanz bezieht, hat "number" den Wert "1" und so weiter. Wenn es sich auf alle Instanzen bezieht, kann "number" den Wert "all" haben.
Eine abgeleitete Attributdefinition weist zwei Komponenten auf: die Argumente, welche in der Definition verfügbar sind, und die eigentliche Definition, welche als Ausdruck angegeben ist. Das "name"-Attribut gibt den Namen des abgeleiteten Attributs an. Ein abgeleitetes Attribut wird durch das Einstellen der Werte der Argumente und das Auswerten des definierenden Ausdrucks ausgewertet.
Die Komponenten eines Zustands sind eine Liste von Aktionen, welche auszulösen sind, wenn der Zustand erreicht wird, und eine Liste von Transitionen, die von dem Zustand wegführen. Der Name des Zustands wird verwendet, um auf ihn als Ziel irgendeiner Transition zu verweisen.
Die beiden Komponenten einer Transition sind ein Ausdruck, welcher die Transition schützt, und ein Pfad, welcher das Ziel einer Transition bezeichnet. Alle Ausdrücke, Pfade, Aktionen und Definitionen von abgeleiteten Funktionen hängen von deren Ursprung, d.h. der Wurzel des Moduls, bzw. von seinen Instanzen im auszuführenden XML-Dokument ab.
Ein Pfad besteht aus einer optionalen Komponente und einem Attributzustand. Der Zustand bezeichnet den Namen des Zustands, zu welchem der Pfad hinweist. Typische Zustände sind "initial" für den Initial-Zustand und "terminal" für den Endzustand (die Endzustände). Die Komponente verweist auf verschachtelte Komponenten, die Attributnummer bezeichnet wieder die gewählte Instanz. Wenn der Wert der Nummer "all" ist, entspricht der Pfad einer Familie von Pfaden zu allen Instanzen.
Ausdrücke werden an verschiedenen Orten verwendet und definiert wie folgt:
Pfade, die als Ausdrücke verwendet werden, ergeben bei Auswertung das entsprechende Element und nicht den Zustand, auf welchen der Pfad verweist. "Self" ergibt bei Auswertung das Element, welches die Instanz des Moduls ist, welches die Definition enthält, in welcher "self" verwendet wird. "Src" ergibt bei Auswertung das Element, welches den Zustand enthält, der als letzter ausgeführt wurde, wenn es in Aktionen verwendet wird, und das Element, welches die Quelle einer Transition enthält, wenn es innerhalb einer Transition verwendet wird. "Trg" ergibt bei Auswertung das Element, welches das Ziel einer Transition enthält. "Evalattr", "getfirst", "getnext" und "parent" ergeben bei Auswertung die oben beschriebenen entsprechenden Primitive-Funktionen. "Root" ergibt bei Auswertung die Wurzel des Dokuments, welches ausgeführt wird. "Apply" wird für "built" in binären und unären Operatoren wie arithmetischen Operatoren (+, –, *,...), booleschen Operatoren (and, or, not,...) und Stringoperatoren (append, concatenate, ...) verwendet. "External" wird verwendet, um externe Funktionen, die in beliebigen Programmiersprachen geschrieben wurden, aufzurufen. Schließlich wird "constant" verwendet, um konstantenartige Zahlen, d.h. boolesche Werte und Strings, zu bezeichnen.
In den Flussdiagrammen wird eine abstrakte Funktion evaluate(_) verwendet, um Ausdruckselemente auszuwerten.
Aktionen werden ausgelöst, wenn ein Zustand erreicht wird, und weisen folgende Struktur auf:
Die Aktion "setAttr" entspricht dem oben beschriebenen Primitive "setAttr". "Ifthen" wird verwendet, um bestimmte Aktionen nur unter bestimmten Bedingungen auszuführen, und "forall" wird verwendet, um eine Aktion für alle Instanzen eines bestimmten Elements in einem Dokument auszuführen. Das Konstrukt "external" wird wieder verwendet, um externe Funktionen aufzurufen.
In den Flussdiagrammen wird eine abstrakte Prozedur execute(_) verwendet, um Aktionselemente auszuführen.
Da die Definitionen unabhängig von der konkreten Wahl von Ausdruck und Aktionsgrammatik gültig sein sollten, wird die DTD gemäß 9 mit den übrigen Regeln beginnend bei Zeile 19 mit dem Element <!element src EMPTY> fertiggestellt.
Mit Bezugnahme auf 10 bis 16 soll die Ausführung eines bestimmten XML-Dokuments doc.xml ausführlicher erläutert werden. 10 bis 16 zeigen sechs feste Flussdiagramme F1, F2, F2, F3, F4 und F7, welche den Ausführungsprozess spezifizieren. Im Gegensatz zu den GFCs, welche im Kontext der ersten Ausführungsform beschrieben wurden, hängen diese Flussdiagramme nicht vom auszuführenden Dokument und den Roboter-Modulen ab, sondern sind für jedwedes Dokument und jedwedes Roboter-Modul fest. Jedes Flussdiagramm bezieht sich auf einen logischen Block der Ausführung eines bestimmten auszuführenden XML-Dokuments doc.xml. Die Module werden als getrennte moduleX.xml-Dateien für jeden Element-Namen X bereitgestellt. Auf die Zustände jedes Flussdiagramms Fy wird mittels [Fx.Sy] verwiesen, wobei x die Nummer des Flussdiagramms darstellt und y die Zustandsnummer innerhalb des entsprechenden Flussdiagramms darstellt.
Gemäß der Erfindung wird das XML-Dokument (oder in anderen Ausführungsformen eine DTD) zuerst durchlaufen, und alle Zustände und Transitionen von den Modulen werden in das XML-Dokument kopiert. In weiterer Folge wird das XML-Dokument unabhängig ausgeführt. Während des Kopierprozesses wird das Attribut "origin" jedes Zustands auf das gerade durchlaufene Element gesetzt, z.B. das Element, von welchem aus die Kopieraktion ausgelöst wurde. Die Werte des Attributs "origin" sind somit Verweise auf Elemente von doc.xml.
Der Initial-Zustand der Ausführung, welcher in 10 dargestellt ist, ist [F1.S1]. Der Wert der globalen Variablen cur wird auf einen Verweis auf die Wurzel des Dokuments "doc.xml" gesetzt. Dann wird die Steuerung zum Zustand [F1.S2] weitergeführt, wobei der Wert der globalen Variablen mod derart gesetzt wird, dass er ein Verweis auf das Element "module" ist, welches das Ausführungsverhalten der Wurzel beschreibt, z.B. das Modul, welches den Namen aufweist, der dem Label von cur entspricht. Dann wird die Steuerung zu dem Zustand [F2.S1] des Flussdiagramms F2 weitergeführt. Der Zweck von F2 ist, alle "state"- und "derived"-Elemente von dem Modul mod in das Element cur zu kopieren, wobei das Attribut "origin" aller "state"s und "derived" auf cur gesetzt wird. Von dem letzten Zustand [F2.S99] in F2 wird die Steuerung zu dem ersten Zustand [F3.S1] von F3 weitergeführt. Der Zweck von F3 ist, die "state"- und "derive"-Elemente der Untermodule des Moduls mod in die entsprechenden Komponenten des Elements cur zu kopieren, wobei das Attribut "origin" aller "state"- und "derived"-Elemente auf cur gesetzt wird. Von dem letzten Zustand [F3.S99] von F3 wird die Steuerung zu [F1.S3] weitergeführt, wobei cur auf cur.traverse aktualisiert wird. Dann verzweigt sich die Entscheidung [F1.D1] nach der Bedingung cur = undef. Wenn die Bedingung bei Auswertung wahr ergibt, wird der Durchlauf beendet, und die Steuerung wird zu [F5] weitergeführt, wobei andernfalls die Steuerung zu [F1.S2] zurückgeführt wird.
Modul F5 kann ergänzende Prozeduren enthalten, um Module, die in verschachtelten Modulen verschachtelt sind, zu verarbeiten und Sicherheitsbedingungen zu überprüfen. Diese Prozeduren, welche lediglich in besonderen Ausführungsformen verwendet werden, können mittels Standardprozessstrukturen implementiert werden. Von [F5] wird die Steuerung zu [F6] weitergeführt. Das Modul F6 wird wiederum lediglich für besondere Ausführungsformen verwendet und enthält Zustände, Transitionen und abgeleitete Attribute, welche gemäß verschiedenen Grundsätzen, beispielsweise Präferenzen hinsichtlich der Bedingungen in Transitionen und dergleichen, die zu implementieren sind, neu geordnet werden. Von [F6] wird die Steuerung zum ersten Zustand von F7, zu [F7.S1], weitergeführt.
Wie festgehalten wurde, ist der Zweck von F2 (11), die "state"- und "derived"-Elemente des Moduls mod in das Element cur zu kopieren und die "origin"-Attribute dieser Elemente auf cur zu setzen. Anstatt zunächst die Elemente zu kopieren und dann die Attribute zu setzen, werden die Attribute im Modul mod auf den richtigen Wert gesetzt, und daraufhin werden die "state"- und "derived"-Elemente von dem Modul mod in das Element cur kopiert. Eine globale Variable state wird verwendet, um "state"-Elemente in mod zu umspannen, und eine globale Variable derived wird verwendet, um "derived"-Elemente zu umspannen. Der erste Zustand [F2.S1] setzt die Variable state auf das erste "state"-Element in mod. Dann wird die Steuerung zu [F2.D1] weitergeführt, und von dort wird die Steuerung zu [F2.S3] weitergeführt, wenn state = undef, und andernfalls zu [F2.S4]. In [F2.S3], welcher erreicht wird, wenn state nicht gleich undef ist, wird das Attribut "origin" von state auf cur gesetzt. Von dort wird die Steuerung zu [F2.S3] weitergeführt, wobei state auf state.getNext gesetzt wird. Von dort wird die Steuerung wieder zu der Entscheidung [F2.D1] geführt. In [F2.S4], welcher erreicht wird, nachdem alle "state"-Elemente kopiert wurden, wird die globale Variable derived auf das erste "derived"-Element gesetzt. Auf dieselbe Weise wie für die "state"-Elemente werden die Entscheidung [F2.D2], welche sich bei derived=undef verzweigt, und der Zustand [F2.S6], der derived::= derived.getNext auslöst, verwendet, um über allen "derived"-Elementen einer Iteration unterzogen zu werden, und in [F2.S5] wird das Attribut "origin" auf cur gesetzt.
Wenn die Iteration endet, wird die Steuerung zu [F2.S7] weitergeführt, wobei die gesamte Liste von "derived"s in "cur" eingefügt wird. Dann wird in [F2.S99] die Liste von "state"-Elementen von "mod" kopiert und in "cur" eingefügt.
In F3 (12) werden unter Verwendung der Iterationsvariable submod alle Untermodule von mod durchlaufen. Wenn die Iteration endet, z.B. wenn die Entscheidung [F3.D1] submod bei Auswertung "undef" ergibt, wird die Steuerung an den letzten Zustand von F3, [F3.S99], weitergegeben. Andernfalls wird die Steuerung zu [F3.S2] weitergeführt, wo die Variable subcur auf die erste Komponente gesetzt wird, deren Label mit dem Label des Untermoduls submod übereinstimmt. Wenn das "number"-Attribut des Untermoduls submod "1" oder "all" ist, wird subcur richtig auf die erste Instanz gesetzt und die Steuerung von Entscheidung [F3.D2] zum ersten Zustand von F4, [F4.S1], weitergeführt. Andernfalls wird in [F3.S3] subcur auf die nächste Instanz gesetzt, und die Steuerung wird zur Entscheidung [F3.D3] weitergeführt, welche überprüft, ob subcur "undef" ist. Wenn dies nicht der Fall ist, wird angenommen, dass die zweite Instanz oder alle überprüft werden müssen, und die Steuerung wird wieder zum Zustand [F4.S1] geführt. Der Zweck von F4 ist genau derselbe wie jener von F2, wobei jedoch anstatt mod und cur, submod und subcur verwendet werden, abgesehen von dem Attribut "origin", welches auf cur gesetzt wird.
Vom Endzustand [F4.S99] wird die Steuerung zu der Entscheidung [F3.D4] weitergeführt. Wenn die Abzweigbedingung durch Auswertung des Attributs "number" von submod "all" ergibt, wird die Steuerung an [F3.S3] weitergeführt und durchläuft alle Instanzen mit dem richtigen Label. Wenn dieser Durchlauf angehalten wird, durch Auslösen der Entscheidung [F3.D3] auf wahr oder durch Finden in der Entscheidung [F3.D4], dass die Nummer nicht "all" war, wird das Durchlaufen aller Untermodule im Zustand [F3.S4] fortgesetzt. Dort wird submod auf die nächste Instanz von"module"-Elementen gesetzt. Von [F3.S4] wird die Steuerung wieder zur Entscheidung [F3.D1] weitergeführt, welche, wie festgehalten wurde, entweder mit dem Durchlaufen von Untermodulen fortfährt oder die Steuerung zum letzten Zustand von F3, d.h. [F3.S99], sendet.
Wie oben erwähnt wurde, funktioniert F4 (13) genau wie F2. Die Variablen state und derived werden verwendet, um eine Iteration über die "state"-Elemente und "derived"-Elemente des Moduls "submod" durchzuführen, wobei ihr "origin"-Attribut auf das Element "cur" gesetzt wird. Dann werden alle "state"- und "derived"-Elemente kopiert und in das Element subcur eingefügt.
Bei Zustand [F4.S99] werden alle "state"-Elemente und "derived"-Elemente in die entsprechenden Elemente des Dokuments doc.xml kopiert, und das Attribut "origin" wird gesetzt, derart, dass die Module nicht mehr benötigt werden. Da nur ein Attribut von "state" gesetzt werden muss und alle "transition""action"- und "derived"-Elemente unberührt sind und bleiben, wäre eine Alternative, nur den äußersten Teil der "state"-Elemente und "derived"-Elemente zu kopieren und Verweise auf die Module für den Rest zu verwenden.
Der erste Zustand [F7.S1] des Flussdiagramms F7, welches in 14 dargestellt ist, bezeichnet den Beginn der eigentlichen Ausführungsphase. In F7 werden die Aktionen aller Zustände, welche mit dem aktuellen Zustand "curstate" übereinstimmen, ausgelöst.
[F7.S1] setzt cur zurück auf die Wurzel des Dokuments doc.xml. Dann geht die Steuerung zu [F7.S2] weiter, wo die globale Variable curstate auf "initial" gesetzt wird. Der Zweck von curstate ist es, den aktuellen Zustand anzuzeigen, innerhalb des aktuellen Elements cur. In [F7.S3], [F7.D1] und [F7.S9] wird die variable state einer Iteration über alle "state"-Elemente des aktuellen Elements cur unterzogen. [F7.S3] initialisierte die Iteration, [F7.D1] ist das Beendigungskriterium, von dem die Steuerung bei Beendigung zu [F8.S1] weitergeführt wird, und [F7.S9] ist der eigentliche Iterator, welcher state auf die nächste Instanz von "state"-Elementen setzt. Innerhalb der Iteration überprüft die Entscheidung [F7.D2], ob das Attribut "name" von state mit dem aktuellen Zustand curstate übereinstimmt. Wenn dies der Fall ist, geht es als nächstes weiter zu [F7.S4], wobei die Variable cur auf den Wert des Attributs "origin" von state gesetzt wird. Der Zweck dieser Aktualisierung ist es, die Aktionen in der richtigen Umgebung auszuwerten. In [F7.S5], [F7.D3] und [F7.S7] wird die Variable action einer Iteration über alle Aktionen innerhalb von state unterzogen, und alle diese werden in [F7.S6] ausgeführt. Wenn diese Iteration endet, wird die Steuerung zu [F7.S8] weitergeführt, wo der Wert von cur auf seinen ursprünglichen Wert rückgesetzt wird. Von dort erfolgt ein erneuter Eintritt in die Iteration über Zustände, was nach der Beendigung zu [F8.S1] führt.
Schließlich werden in F8, welches in 15 dargestellt ist, die Transitionen ausgelöst, welche das aktuelle Element cur und den aktuellen Zustand curstate aktualisieren. Die Auswertung der Transitionsbedingungen hängt von dem Ursprung ihrer Definition, dem Quellelement src der Transition und dem Zielelement trg der Transition ab. Im Element "expression", welches die Bedingung bezeichnet, kann auf diese drei Elemente als <self />, <src/> bzw. <trg/> zugegriffen werden. Im Flussdiagramm F8 finden zwei verschachtelte Iterationen über die "state"-Elemente und über deren "transition"-Elemente statt. Der erste Zustand [F8.S1] setzt src auf das aktuelle Element cur. Dann unterziehen [F8.S2], [F8.D1] und [F8.S9] die Variable "state" einer Iteration über alle Zustände im aktuellen Element cur. Wenn die Iteration endet, wird die Steuerung an [F7.S3] zurückgegeben, wobei wieder dieselben Aktionen ausgeführt werden. Andernfalls überprüft [F8.D2], ob das Attribut "name" von state mit dem aktuellen Zustand curstate übereinstimmt. Wenn dies der Fall ist, erfolgt ein Einstieg in [F8.S4], und cur wird auf den Wert des Attributs "origin" gesetzt. Dann werden [F8.S5], [F8.D3], [F8.S8] verwendet, um die Variable trans einer Iteration über alle Transitionen innerhalb von state zu unterziehen. Innerhalb der Iteration setzt [F8.S6] trg auf das Resultat des Auswertens des Pfads. Dann überprüft [F8.D4], ob der Ausdruck von trans bei Auswertung wahr ergibt. Es muss festgehalten werden, dass für diese Auswertung die richtigen Einstellungen von cur, src und trg benötigt werden. Wenn das Ergebnis der Auswertung wahr ist, wird cur auf trg gesetzt, und curstate wird auf das "state"-Attribut der Pfad-Komponente von trans gesetzt. Dann wird die Steuerung an [F7.S3] weitergegeben, um die Aktionen des neuen aktuellen Elements und Zustands auszuführen.
In 16, 17 und 18 werden Module des Abfragesprachenbeispielsgemäß 1 ff gezeigt. Diese Module sind in Bezug auf die DTD, welche in 11 angegeben ist, gültig. Die Ausführung des Beispiel-XML-Dokuments kann mittels des Prozesses, der in 12 ff beschrieben wird, durchgeführt werden. Die Module können automatisch aus einer grafischen Eingabe gemäß den oben beschriebenen grafischen Flussdiagrammen generiert werden. Andererseits könnte ihre grafische Darstellung aus der hier angegebenen Textform generiert werden.
Bezugnehmend auf 19a–19b wird die Implementierung einer XML-Roboterspezifikation, welche das Ausführungsverhalten von XML-Dokumenten, wie oben erläutert wurde, angibt, ausführlicher beschrieben. In Anbetracht einer XML-Roboterspezifikation m0, die in einer XML-Roboterspezifikationssprache M geschrieben ist, beispielsweise in der oben beschriebenen visuellen/textlichen Abfragesprache, und eines XML-Dokuments d, welches in Bezug auf die Dokumenttypdefinition von m0, und zwar DTD0, gültig ist, gibt die Ausführungsspezifikation alle Informationen darüber an, was ein abstrakter Prozess m0Exec(d) tun muss, um d auszuführen. Um den abstrakten Prozess m0Exec(d) zu implementieren, ist ein Programm erforderlich, welches auf bestehenden Rechnern ausgeführt werden kann, z.B. ein Programm, welches in einer Programmiersprache wie C oder Java geschrieben ist. Es gibt vier grundlegende Möglichkeiten, das Programm zu implementieren.
In 19a–19d sind Prozesse als Kästchen visualisiert, Dokument sind auf die übliche Weise visualisiert, d.h. ein Kästchen mit einer geschwungenen oberen Seite, und ein ausführbares Dokument, z.B. ein Programm, ist als Kombination aus einem Dokument und einem Prozess, z.B. der Ausführung des Programms, visualisiert. Jeder Prozess kann eine Eingabe in Form von Dokumenten, eine Ausgabe in Form von Dokumenten aufweisen, und er kann einen anderen Prozess starten. Konkrete Prozesse, welche auf einer realen Maschine ausgeführt. werden können, sind als Kästchen mit durchgezogenen Linien dargestellt, und abstrakte Prozesse, beispielsweise der Prozess m0Exec(d), sind als Kästchen mit gestrichelten Linien dargestellt. Die beschriebenen Möglichkeiten des Implementierens von XML-Robotern sind verschiedene Kombinationen aus Compiler- und Interpretermethoden. Eine beliebige der beiden Methoden kann für den Metaformalismus M und den Formalismus DTD0 verwendet werden. Somit gibt es für gewöhnlich vier Kombinationen, einen Compiler gefolgt von einem Interpreter (19a), einen Compiler gefolgt von einem Compiler (19b), einen Interpreter gefolgt von einem Interpreter (19c) und einen Interpreter gefolgt von einem Compiler (19d)
19a zeigt eine Implementierung durch Generieren eines Interpreters IntDTD0 aus der XML-Spezifikation m0. Der Interpreter IntDTD0 verwendet als Eingabe ein XML-Dokument d und überprüft, ob es in Bezug auf DTD0 gültig ist. Daraufhin startet er einen Prozess, welcher ein derartiges Dokument d ausführt, derart, dass der Prozess mit dem oben vorgestellten abstrakten Prozess m0Exec(d) äquivalent ist. Die Implementierung wird durch ein ausführbares Dokument IG angegeben, dessen Ausführung als Eingabe eine XML-Roboterausführungsspezifikation m0 verwendet und als Ausgabe ein ausführbares Dokument IntDTD0, d.h. den Interpreter, generiert.
19b visualisiert eine nächste Möglichkeit durch Bereitstellen eines Compilergenerators, der durch ein ausführbares Dokument CG angegeben wird, welches einen Compiler CompDTD0 aus der XML-Spezifikation m0 generiert. Der Compiler CompDTD0 wandelt ein Dokument d, das als Eingabe empfangen wurde, in ein ausführbares Dokument d' um, dessen Ausführung mit dem abstrakten Prozess m0Exec(d) äquivalent sein muss.
19c zeigt einen Interpreter IntMtoInt der Spezifikationssprache M, welcher einen Interpretationsprozess von m0 startet. Der Interpreter IntMtoInt verwendet als Eingabe eine XML-Roboterspezifikation m0 und startet einen Prozess IntDTD0, der als Eingabe ein XML-Dokument d verwendet. Der Prozess IntDTD0 startet nun einen nachfolgenden Prozess, der das Dokument d ausführt, wobei der Prozess mit dem abstrakten Prozess m0Exec(d) äquivalent sein muss.
Als eine letzte Möglichkeit zeigt 19d einen Interpreter IntMtoComp der Spezifikationssprache M. Der Interpreter IntMtoComp verwendet eine XML-Roboterspezifikation m0 als Eingabe, startet jedoch im Gegensatz zum zuvor beschriebenen Interpreter IntMtoInt einen Compilerprozess CompDTD0, der als Eingabe ein XML-Dokument d verwendet und als Ausgabe ein ausführbares Dokument d' generiert, dessen Ausführung wieder mit der Ausführung des abstrakten Prozesses m0Exec(d) äquivalent sein muss.
Es kann einfach erkannt werden, dass jede der oben genannten Möglichkeiten spezifische Vor- und Nachteile aufweist. Wie bekannt ist, ist der Vorteil des Verwendens von Interpretertechnologie die unmittelbare Verfügbarkeit der Ausführung, wobei die Vorteile der komplexeren Compilertechnologie sowohl eine bessere Leistung als auch die Verfügbarkeit der generierten ausführbaren Dokumente sind, welche getrennt wiederverwendet werden können, unabhängig von der XML-Roboterspezifikation m0.
In 20 wird eine bevorzugte Ausführungsform eines XML-Roboters auf Webbasis dargestellt. Ein Server 21, für gewöhnlich ein leistungsstarker Web-Server, ist mit einer Datenbank 22 und einer oder mehreren Funktionalitätsbibliotheken 23 verbunden. Mittels Netzverbindungen, insbesondere über das Internet, können ein oder mehrere Clients 25.1, 25.2, die sich für gewöhnlich eines Browsers bedienen, der auf einem abgesetzten System läuft, auf den Server 21 zugreifen. Die Kapazitäten dieser Clients 25.1, 25.2 sind mehr oder weniger eingeschränkt und können für gewöhnlich für den Betrieb eingeschränkter abstrakter Maschinen wie der Java Virtual Machine dienen.
Der Server 21 stellt den Dienst bereit, um die XML-Dokumente gemäß einer XML-Roboterspezifikation, wie oben beschrieben wurde, auszuführen. Die Aktionen in der XML-Roboterspezifikation sind auf dem Server 21 auszuführende Aktionen, z.B. Zugriff auf die Datenbank 22 des Servers oder Aufrufe der Funktionalitätsbibliotheken 23 des Servers. Darüber hinaus sind Aktionen und möglicherweise zusätzliche Geräte 27 für das Veröffentlichen von Resultaten über E-Mail, Webseiten, WAP, SMS und dergleichen, das Verwalten von Zugriffsrechten und das Verwalten der Architektur der zugrundeliegenden Datenbanken und Softwaresysteme verfügbar. Die XML-Roboterspezifikation kann nur auf dem Server 21 ausgeführt werden, sie kann jedoch als Dokumentation des Dienstes, der dem Client bereitgestellt wird, dienen.
Die Situation ist mit einem Application-Service-Provider-Modell (ASP-Modell) vergleichbar, wo Anwendungen auf einem Server laufen und alle Arten von Clients darauf zugreifen können. Die vorliegende Erfindung weist ebenfalls den Vorteil von ASP auf, dass alle Berechnungen auf dem Server erfolgen, und deshalb können die Clients äußerst kleine Vorrichtungen wie Internet-Vorrichtungen sein. Weiterhin bietet die Erfindung den Vorteil, dass eine endliche XML-Roboterspezifikation unendlich viele verschiedene XML-Dokumente ausführen kann, welche mit der entsprechenden DTD übereinstimmen.
Die Anwendungen der Execution-Service-Provider-Lösung reichen von Eingabe/Steuerung bestehender Anwendungen zur Spezifikation und sogar zur Programmierung von neuen Anwendungen. Die Eingabe/Steuerungs-Anwendungenbedienen sich der XML-Dokumente, um eine Anwendung zu steuern. Die XML-Roboterspezifikation würde einfach die Dokumente in interaktive Eingabe/Steuerungs-Sequenzen für die zu steuernde Anwendung übersetzen. Im Fall der Spezifikation/Programmierung neuer Anwendungen entsprechen die XML-Dokumente Syntaxbäumen von Programmen und die XML-Roboterspezifikation gibt das Ausführungsverhalten an. Beispielsweise würde es eine XML-Roboterspezifikation mit einer DTD, welche Syntaxbäume für die Programmiersprache C darstellt, und wobei der XML-Roboter deren Ausführungsverhalten angibt, ermöglichen, beliebige C-Programme zu dem Server zu senden und dort ausführen zu lassen.
Im Gegensatz zu der zuvor beschriebenen Ausführungsform mit einem Execution Service Provider kann eine andere bevorzugte Ausführungsform LangLets (kleine XML-Roboterspezifikation)bzw. Mobile Languages bereitstellen. In diesem Fall stellt der Server 21 Dienste für die Clients 25.1, 25.2 bereit, indem er zunächst eine XML-Roboterspezifikation und dann die XML-Dokumente, welche gemäß der Spezifikation ausgeführt werden sollten, sendet. Diese Ausführungsform benötigt Clients 25.1, 25.2, die in der Lage sind, einen Interpreter/Compiler aus der XML-Roboterspezifikation zu generieren, um die XML-Dokumente auszuführen. Die Aktionen der XML-Roboterspezifikation werden auf den Clients 25.1, 25.2 dementsprechend ausgeführt. Diese Lösung kann in einem weiteren Sinne mit dem Senden von Java-Code an einen Client, welcher in weiterer Folge diesen Code ausführt, verglichen werden. Allerdings ist das durch eine XML-Roboterspezifikation angegebene Ausführungsverhalten weit einfacher und weit weniger ausdrucksstark als komplettes Java. Eine Sprache wie Java kann jedoch verwendet werden, um die Aktionen der XML-Roboterspezifikation zu programmieren. Das Ausführungsverhalten aller XML-Dokumente (unendlich viele), die gemäß einer derartigen XML-Roboterspezifikation ausgeführt werden, wird dann auf die endliche Anzahl fester (jedoch parameterisierter) Java-Aktionen in der XML-Roboterspezifikation beschränkt.
Ein bedeutender Vorteil der vorliegenden Erfindung ist, dass Sicherheitseigenschaften einer endlichen XML-Roboterspezifikation untersucht werden können. Diese Eigenschaften können dann gewährleistet bzw. überprüft werden, für eine unendliche Anzahl verschiedener XML-Dokumente, die auf den Clients 25.1, 25.2 ausgeführt werden sollen. Wenn beispielsweise eine bestimmte kritische Sicherheitsaktion nicht in den Aktionen der XML-Roboterspezifikation enthalten ist, kann gewährleistet werden (direkt auf der Grundlage der Definitionen), dass diese Aktion nicht für irgendein XML-Dokument ausgeführt wird, welches gemäß dieser XML-Roboterspezifikation ausgeführt wird. Oder es kann gewährleistet werden, dass, wenn eine andere kritische Sicherheitsaktion nur durch einen Zustand ausgelöst wird, der durch eine bestimmte Bedingung geschützt wird, diese Aktion nur ausgelöst wird, wenn diese Bedingung erfüllt ist.
Auch hier kann es hilfreich sein, an den mobilen Code zu denken, wobei Source-Code über das Netz gesendet wird. Allerdings wird im Gegensatz dazu hier zunächst eine XML-Roboterspezifikation gesendet, welche das Ausführungsverhalten der mobilen Sprache/DTD angibt, und dann werden die Programme/XML-Dokumente übertragen. Somit wird eine mobile Sprache über ein bestimmtes Netz bereitgestellt. Der Vorteil von mobilen Sprachen gegenüber mobilem Code ist, dass sich wiederholende Berechnungen auf generische Weise in die XML-Roboterspezifikation eingebettet sind und die XML-Dokumente, welche die eigentlichen Instanzen der Berechnungen beschreiben, weniger komplex sind.
Eine derartige Verwendung des erfindungsgemäßen XML-Roboters ermöglicht die Definition einer neuen Sprache und Code, der in der Sprache geschrieben wurde, auszuführen, nachdem ein entsprechender Compiler und/oder Interpreter generiert wurde. Ferner ist es möglich, Editoren, Debugger und Analyse-Tools zu erstellen. Die beschriebenen Daten- und Code-Synergien ermöglichen es, die Ausführung oder andere Verarbeitungen eines gültigen XML-Dokuments ohne Schreiben eines eigenen Programms, welches den Strukturbaum eines derartigen Dokuments explizit parst und analysiert, direkt zu definieren.
Die Erfindung sieht eine Vorrichtung 25.1, 25.2, insbesondere Internet-Vorrichtungen, vor, welche innerhalb einer Netzumgebung, insbesondere dem Internet, verwendet werden kann und Mittel zum Empfangen von Daten von und Senden von Daten zu einem abgesetzten Rechner umfasst. Die Vorrichtung sieht Mittel zum Speichern von und Zugreifen auf Daten (XML-Dokument), die von dem abgesetzten Rechner gesendet werden, vor. Die Vorrichtung umfasst vorzugsweise ein Mittel, welches derartige Daten, die von dem abgesetzten Rechner empfangen wurden, überprüfen und gegebenenfalls validieren kann, wenn es sich bei derartigen Daten um eine gültige und/oder zulässige XML-Roboterspezifikation handelt. Die Vorrichtung umfasst weiterhin ein Mittel, welches die XML-Roboterspezifikationen mit einem XML-Dokument integrieren kann. Das XML-Dokument wird dann durch die Vorrichtung, vorzugsweise durch eine Verarbeitungseinheit, welche die Befehle der XML-Dokumente ausführen kann, ausgeführt. Einschlägig versierte Fachleute werden unschwer erkennen, dass das durch diese Vorrichtung umfasste Mittel auf derartige Weise integriert sein kann, dass z.B. die Verarbeitungseinheit für die Ausführung des XML-Dokuments eine Funktionalität für den Sende-/Empfangsbetrieb dieser Vorrichtung bereitstellen kann. Ferner umfasst die Vorrichtung für gewöhnlich eine Benutzerschnittstelle, welche, so dies gewünscht wird, ein Mittel zum Animieren der Ausführung und zur Analyse von XML-Dokumenten oder XML-Roboterspezifikationen bereitstellen kann. Allerdings kann sie nur als Servicestation innerhalb eines Netzes dienen.
Die Erfindung stellt weiterhin eine Vorrichtung bereit, welche ein Mittel zum grafischen Anzeigen von XML-Roboterspezifikationen, z.B. wie mit Bezugnahme auf 3 ff. beschrieben wurde, in einer fortgeschrittenen visuellen integrierten Entwicklungsumgebung umfasst. Gemäß der oben genannten Spezifikation werden diese grafischen Darstellungen verwendet, um XML-Dokumente zu generieren, welche die XML-Roboterspezifikationen darstellen.
Ferner ermöglicht es die Erfindung, die verteilte Ausführung von XML-Dokumenten vorzusehen. Mehrere XML-Roboter werden dann verwendet, um eine Berechnung von XML-Dokumenten auf Grund der Tatsache, dass die Struktur der Dokumente zugleich die Struktur der Anwendung ist, welche diese verarbeitet, zu verteilen. Demzufolge können Teile eines XML-Dokuments einfach auf verschiedenen Instanzen des XML-Roboters, die an verschiedenen Orten angeordnet sein können, ausgeführt werden. Gleichermaßen können spezielle Anwendungen voraussetzen, dass ein Teil des Dokuments auf der Server-Seite und ein Teil des Dokuments auf der Client-Seite ausgeführt wird.

Claims

Verfahren zur direkten Ausführung von XML-Dokumenten, umfassend die folgenden Schritte: Definieren des lokalen Verhaltens und Prozesses für jedes Element eines XML-Dokuments; Integrieren von ausführbaren Befehlen in eine Dokumenttypdefinition (DTD), ein XML-Dokument oder ihre Darstellung als Strukturbaum und Speichern von Zwischenzuständen durch dynamisches Schaffen und Neudefinieren von Elementattributen.
Verfahren nach Anspruch 1, welches ferner die folgende Schritten umfasst: a) Integrieren von ausführbaren Befehlen indem für jede XML-Elementdefinition und ihre Instanzen eine zusammengesetzte Aktion definiert wird, deren Bestandteile sowohl einfache, ausführbare Aktionen als auch Verweise auf Aktionen sind, welche für eine der Komponenten des Elements oder irgend ein anderes Element definiert ist; b) Ausführen eines XML-Dokuments durch Ausführen der Aktion, welche für seine Wurzel definiert ist.
Verfahren nach einen der vorhergehenden Ansprüche, welches ferner den folgenden Schritt umfasst: Definieren der Zusammensetzung der Aktion für wenigstens eine XML-Elementdefinition oder eine XML-Elementinstanz durch graphische Flussdiagramme, welche einen sequenziellen oder gleichzeitigen Steuerungsablauf und/oder Datenfluss darstellen.
Verfahren nach einen der vorhergehenden Ansprüche, welches ferner den folgenden Schritt umfasst: Definieren der Zusammensetzung der Aktion für wenigstens eine XML-Elementdefinition oder (ORIGINAL: ein Objekt davon) eine XML-Elementinstanz in Textform, welche einen sequenziellen oder gleichzeitigen Steuerungsablauf und/oder Datenfluss darstellt.
Verfahren nach einem der vorhergehenden Ansprüche, welches eine Darstellung der Systemzustände in Form von ndimensionalen Datenwürfeln und eine offene Schnittstelle zum System durch Lesbar- und Schreibbarmachen der ndimensionalen Würfel für andere Programmier- und/oder Datenbanksysteme aufweist und ferner den Schritt des Zugänglichmachens von Datenstrukturen und Funktionalitäten anderer Programmier- und Datenbanksysteme von innerhalb des beschriebenen Systems umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, welches Module umfasst, die den Prozess für jedes Element definieren.
System zur Verwendung mit dem Verfahren nach einem der vorhergehenden Ansprüche, umfassend einen Server, welcher für wenigstens einen Client Dienste durch Ausführen wenigstens von Teilen eines XML-Dokuments gemäß einer XML-Roboterspezifikation, die vom Client an den Server gesendet wird, bereitstellt, oder einen Server, welcher für wenigstens einen Client Dienste durch Senden einer XML-Roboterspezifikation und eines XML-Dokuments an den Client bereitstellt, so dass der Dienst durch Ausführen wenigstens eines Teils des gesendeten Dokuments auf dem Client gemäß der gesendeten XML-Roboterspezifikation bereitgestellt wird.
Datenverarbeitungssystem, welches Mittel umfasst, die eingesetzt werden, um jeden der Schritte eines der vorhergehenden Ansprüche 1 bis 5 durchzuführen.
Gerät zur Verwendung mit dem Verfahren nach einem der vorhergehenden Ansprüche 1 bis 6, umfassend Mittel zur grafischen Anzeige von XML-Roboterspezifikationen innerhalb einer fortgeschrittenen visuellen integrierten Entwicklungsumgebung und Mittel zum Erzeugen von XML-Dokumenten, welche die XML-Roboterspezifikationen darstellen.
Gerät nach Anspruch 8 oder 9, welches ferner Mittel zum Prüfen, Bewerten oder Animieren von XML-Dokumenten oder XML-Roboterspezifikationen umfasst.