DE10048940A1 - Erzeugen von Dokumenteninhalten durch Transcodierung mit Hilfe von Java Server Pages - Google Patents

Abstract

Ein Verfahren, ein System und ein Computerprogramm, die es ermöglichen, mit Hilfe von Java Server Pages den Inhalt eines von einem Client angeforderten Dokuments zu transcodieren, um das Ausgabedokument gemäß der anwendungsspezifischen Merkmale anzupassen. Die vorliegende Erfindung ermöglicht dem JSP-Autor insbesondere, Merkmale der Eingabequellenanforderung zu überschreiben und Transcodierungshinweise anzugeben, die von einem Transcodierungsfilter zur Auswahl der geeigneten Formatvorlage verwendet werden.

Description

HINTERGRUND DER ERFINDUNG Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich auf ein Computersystem und befasst sich insbesondere mit einem Verfahren, einem System und einem Computerprogramm für die Verwendung von Java Server Pages zum Erzeugen von anwendungsspezifischen Dokumenteninhalten. Die dargelegte Technik ermöglicht dem Autor von JSP-Anwendungen mehr Möglichkeiten bei der Gestaltung des Inhalts eines von einem Client angeforderten Dokuments, das durch die Anwendung des Autors erzeugt wurde.

Beschreibung des technischen Hintergrunds

Das "Transcodieren" ist eine auf diesem Gebiet bekannte Technik. Im Allgemeinen übersetzt oder transformiert dabei ein Transcoder den Inhalt eines Dokuments oder einer Datei so, dass ein anderes Dokument bzw. eine andere Datei erzeugt wird. In Internet- und WWW-basierten Umgebungen gibt es für das Transcodieren zahlreiche Verwendungsmöglichkeiten. Durch Transcodierung kann beispielsweise eine in ein Web-Dokument eingebettete farbige Grafik zur Verringerung der Größe des Informationsinhalts in eine Graustufengrafik umgewandelt werden, bevor die Grafik von einem Server an einen Client übertragen wird, der das Dokument angefordert hat. Ein weiteres Beispiel stellt die Übersetzung eines HTML-Dokuments (HyperText Markup Language) in ein XML-Dokument (Extensible Markup Language) dar, bevor dieses an einen Client übertragen wird. ("XML" ist ein Warenzeichen des Massachusetts Institute of Technology.) Dem Fachmann erschließen sich für das Transcodieren viele weitere Verwendungsmöglichkeiten.

Servlets haben sich bei der Erzeugung von dynamischen Web- Inhalten als ein besonders leistungsstarkes Tool erwiesen. Ein Servlet ist ein typischerweise in der objektorientierten Programmiersprache Java geschriebenes Programm. (Java ist ein Warenzeichen von Sun Microsystems, Inc., im Folgenden als "Sun" bezeichnet.) Ein Servlet wird so erzeugt, dass es problemlos dem bereits auf einem Server installierten Code hinzugefügt werden kann, und es dient der Erweiterung der vom Server gebotenen Funktionalität. Ein Servlet implementiert typischerweise einen Code zur Ausführung einer bestimmten Aufgabe, wie beispielsweise das Abfragen von Informationen aus einer bestimmten Datenbankart, das Ausführen von Funktionen einer geschäftlich genutzten Anwendung oder das Durchführen einer bestimmten Transcodierungsoperation. Ein für die Transcodierung verwendetes Servlet kann ein statisches Dokument (d. h. ein Dokument mit vordefiniertem Inhalt) bearbeiten, um den Inhalt dieses Dokuments wie weiter oben beschrieben (d. h., durch das Bearbeiten von Bildern, das Übersetzen von einer Syntax in eine andere usw.) in eine andere Form zu bringen. Servlets können außerdem zur dynamischen Erzeugung des Inhalts oder Teilen des Inhalts einer angeforderten Web-Seite verwendet werden. Durch das Ausführen eines Servlets können Laufzeitinformationen wie die Identifizierung des Clients, der das Dokument anfordert, abgerufen werden. Diese dynamisch abgerufenen Informationen lassen sich anschließend beim Erzeugen des an den Client zu übertragenden Ausgabedokuments verwenden (beispielsweise kann eine client-spezifische Anrede in das Dokument eingebunden werden; das Dokumentformat kann auf die für den Client gespeicherten Einstellungen zugeschnitten werden; usw.).

Sun hat vor kurzem eine serverseitige Prozedursprache definiert, die unter dem Namen "Java Server Pages" oder "JSP" bekannt ist. Diese JSP-Sprache ermöglicht den Zugriff auf die Servlet-API (Application Programming Interface), die Schnittstelle des Servlets zur Programmierung von Anwendungsprogrammen, die Java-API und die JavaBeans-API. Das JSP-Modell vereinfacht die Entwicklung von Servlets, indem gewährleistet wird, dass der Servlet-Code ein Prozedurparadigma verwendet, sodass Softwareentwickler in die Lage versetzt werden, auf einfachere Weise Anwendungen zu erstellen, die Web-Inhalte dynamisch erzeugen. Der Einsatz von Servlets wird zudem vereinfacht, da zur Verwendung von JSP lediglich ein Web-Dokument (beispielsweise eine HTML-Seite oder ein XML-Dokument) aufgerufen werden muss, in das der JSP- Code eingebettet ist. Während der Verarbeitung des Web- Dokuments wird der Servlet-Code, auf den verwiesen wird, automatisch von der JSP-Engine aufgerufen. (Fachleuten ist bekannt, dass das Aufrufen einer Web-Seite durch die Übertragung eines HTTP-Protokolls (HyperText Transfer Protocol) von einem Client zu einem Web-Server erfolgt, wobei durch diese GET-Anforderung der einheitliche Ressourcen- Lokalisierer (Uniform Resource Locator, URL) festgelegt wird, der zur Lokalisierung der gewünschten Seite verwendet wird.) Java Server Pages integrieren das Prinzip "Write Once, Run Anywhere" der Programmiersprache Java und ermöglichen die Definition von Servlets durch Prozeduren, auf die Web- Anwendungsserver problemlos zugreifen können. Ein weiterer Vorteil von Java Server Pages liegt darin, dass der von Server zu Server unterschiedlich ablaufende Servlet- Registrierungsprozess nicht länger erforderlich ist. ("JavaServerPages", "Java Beans" und "Write Once, Run Anywhere" sind Warenzeichen von Sun.)

In dem hier dargestellten Datenverarbeitungsmodell, bei dem die Transcodierung mit Hilfe von Servlets erfolgt, ist die Transcodierungs-Engine ein Filter im Ausgabedatenstrom des Anwendungsservers (oder Web-Servers). Diese Transcodierungs- Engine hat typischerweise Zugriff auf Merkmale der Eingabeanforderungsquelle. (Diese Merkmale werden in dem vorliegenden Dokument auch als "Zielkontext" eines angeforderten Dokuments bezeichnet, da der Anforderer typischerweise auch den Empfänger des Ausgabedokuments darstellt.) Beispiele für die Merkmale der Eingabequelle sind: der User Agent (z. B. ein Browser), durch den ein Dokument angefordert wurde; die Vorrichtung, auf der der User Agent operiert; die Netzwerkverbindung, über die die anfordernde Vorrichtung verbunden ist, usw. Einige Aspekte dieser Informationen zu Merkmalen der Eingabequelle können einem Servlet zur Verfügung stehen, das auf dem Web-Server operiert, von dem ein angefordertes Dokument versandt wird. Andere Aspekte dieser Informationen sind im Netzwerk möglicherweise nur an Vermittlungspunkte (beispielsweise an einem Gateway- Computer zu einem drahtlosen oder verkabelten Netzwerk, zu Proxy-Servern für die Transcodierung oder zu Transcodierungsservern) in einer komplexen Lieferkette zwischen dem versendenden Web-Server und dem anfordernden Client verfügbar. Die Transcodierungs-Engine kann diese Merkmale der Eingabeanforderungsquelle für die Auswahl des Transformationsvorgangs verwenden, den sie am Ausgabedokument durchführen wird, um den angeforderten Inhalt in eine Form umzuwandeln, die speziell an die Zielumgebung angepasst ist, in der der Inhalt für den anfordernden Benutzer ausgegeben wird. Wie bereits erwähnt, kann der Filter an einer beliebigen Position des kompletten Netzwerkpfads für die Ausgabe an die anfordernde Vorrichtung angeordnet sein. Idealerweise befindet sich der Filter jedoch im Anwendungsserver selbst. Ein auf dem Anwendungsserver installierter Filter kann an die für die Erzeugung des Ausgabedokuments zuständige Anwendung gekoppelt werden und dadurch eine effiziente und besonders schnelle Abwicklung des Transcodierungsvorgangs gewährleisten.

Wie bereits erwähnt, sind Transcodierungsvorgänge in verschiedenen Ausführungen möglich. Auf dem Markt für die Verarbeitung von Geschäftsdaten hat sich eine Ausführung als besonders bedeutsam herausgestellt, die mit Hilfe eines XSL- Prozessors (Extensible Stylesheet Language, XSL) erstellt wird, der unter Verwendung einer XSL-Formatvorlage XML- Dokumente einschließlich neuer XML-Dokumente in nahezu jedes Zielformat umwandeln kann. Das U.S.-Patent "Retrieval of Style Sheets from Directories Based Upon Partial Characteristic Matching (Seriennummer 09/287,988, vom 8. April 1999) (im Folgenden als "die Referenzerfindung" bezeichnet) legt eine Technik offen, bei der eine geeignete XSL-Formatvorlage für die Verwendung durch eine XSL-Transcodierungs-Engine dynamisch ausgewählt und abgerufen werden kann, um ein Ausgabedokument zu erzeugen, das auf die Merkmale der Eingabeanforderungsquelle zugeschnitten ist. (Die Web-Seiten "Extensible Stylesheet Language (XSL), W3C Working Draft 21 April 1999" und "XSL Transformations (XSLT), Version 1.0, W3C Working Draft 9 July 1999", die im Internet unter http://www.w3.org/TR/WD-xsl bzw. http://www.w3.org/TR/WD-xslt verfügbar sind, enthalten weitere Informationen über die Verwendung von XSL zum Formatieren und Transformieren von Dokumenten.)

Einer der einschränkenden Faktoren dieses Transcodierungsmodells besteht bis heute darin, dass nur die Merkmale der Eingabeanforderungsquelle für die Auswahl der Formatvorlage verwendet werden und sich auf den Inhalt des Ausgabedokuments auswirken, und dass nur sehr geringe Informationen über die das Ausgabedokument erzeugende Anwendung verfügbar sind. Genau genommen steht für die Verarbeitung durch den Transcodierungsfilter nur die Dokumentartdefinition (Document Type Definition, DTD) des gerade transformierten XML-Dokuments als Anwendungsmerkmal zur Verfügung. Typischerweise teilt sich eine gesamte Familie verschiedener Anwendungen eine einzelne gemeinsame DTD. Die von dem Transcodierungsfilter durchzuführende Transformierung sollte jedoch idealerweise anhand von anwendungsspezifischen Merkmalen modifiziert werden. Ein Bankenkonsortium könnte beispielsweise eine einzelne DTD für alle Bankprodukte festlegen. Zu diesen Produkten können zählen: Auszüge für Sparkonten, Girokonten, Kredite oder Einlagenzertifikate, monatliche Kontoauszüge, Kreditanträge, Kontostandabfragen usw. Infolgedessen bietet die DTD lediglich ein komplexes generisches Mittel zur Einflussnahme auf den Inhalt des Ausgabedokuments. Es ist offensichtlich, dass die von der Anwendung für die Erstellung eines Kreditantragsformulars vorzugsweise erzeugten Informationen ganz anderer Natur sind als die Informationen, die für monatliche Kontoauszüge erzeugt würden. Ein weiteres Beispiel für die Vorteilhaftigkeit der Verwendung anwendungsspezifischer Merkmale zum Transcodieren eines Dokuments stellt das Szenario dar, in dem ein Transcodierungsfilter ein HTML-Dokument verarbeitet. Dabei wird die Eingabeseite in einem generischen Transcodierungsprozess von HTML zu XML in ein XML-Dokument konvertiert, während das XML-Dokument anschließend verarbeitet wird, indem in einer XSL-Engine XSL-Formatvorlagen auf das Dokument angewendet werden. In diesem Szenario stellt eine einzelne DTD das einzige für den Transcodierungsprozess verfügbare Anwendungsmerkmal dar. Daher würden an allen HTML- basierten Web-Anwendungen, für die dieses Szenario gilt, dieselben generischen Transformationen vorgenommen werden (die Web-Anwendungen erhielten darüber hinaus die Fähigkeit, einen bestimmten Satz von Eingabeanforderungsmerkmalen zu verwenden, um die Ausgabe noch weiter gemäß dem Zielkontext zu transformieren).

Angesichts der oben erwähnten vorteilhaften Aspekte der Verwendung von Java Server Pages, wäre die Einbindung von Java Server Pages in Transcodierungsumgebungen wünschenswert. Zum gegenwärtigen Zeitpunkt ist keine Technik bekannt, die diese Anforderungen erfüllt. Folglich wird eine Technik benötigt, mit deren Hilfe ein JSP-Autor die in einem Transcodierungsprozess zu verwendenden anwendungsspezifischen Merkmale festlegen kann, und die es ermöglicht, dass die Transcodierungs-Engine eine Ausgabe erzeugt, die genauer auf den anfordernden Benutzer zugeschnitten ist.

ÜBERBLICK ÜBER DIE ERFINDUNG

Ein Ziel der vorliegenden Erfindung ist die Bereitstellung einer Technik zum Einbinden anwendungsspezifischer Merkmale in den Transcodierungsprozess.

Ein weiteres Ziel der vorliegenden Erfindung ist die Bereitstellung dieser Technik in der Art und Weise, dass der JSP-Autor die von seiner Anwendung erzeugte Ausgabe genauer auf die Anforderung eines bestimmten Client abstimmen kann.

Ein weiteres Ziel der vorliegenden Erfindung ist die Bereitstellung dieser Technik in der Art und Weise, dass der JSP-Autor Informationen der Eingabeanforderungsquelle überschreiben kann.

Ein weiteres Ziel der vorliegenden Erfindung ist die Bereitstellung dieser Technik in der Art und Weise, dass der JSP-Autor die Möglichkeit hat, zusätzliche anwendungsspezifische Merkmale in ein zu transcodierendes Dokument einzufügen.

Ein weiteres Ziel der vorliegenden Erfindung ist die Bereitstellung dieser Technik in der Art und Weise, dass die geänderten Kontext- und/oder die eingefügten Merkmalsinformationen zur Auswahl einer geeigneten Formatvorlage für den Transcodierungsprozess verwendet werden können.

Ein weiteres Ziel der vorliegenden Erfindung ist die Bereitstellung dieser Technik in abwärtskompatibler Form, sodass bereits vorhandene Formatvorlagen weiterhin korrekt funktionieren.

Weitere Ziele und Vorteile der vorliegenden Erfindung sind zu einem Teil nachfolgend in der Beschreibung und in den Figuren dargelegt. Zu einem anderen Teil lassen sich diese Ziele und Vorteile aus der Beschreibung erschließen oder bei der praktischen Anwendung der Erfindung nachvollziehen.

Zum Erreichen der genannten Ziele und in Übereinstimmung mit dem bisher ausführlich beschriebenen Zweck der Erfindung, umfasst die vorliegende Erfindung ein Verfahren, ein System und ein Computerprogramm zur Verwendung in einer Datenverarbeitungsumgebung zum Erzeugen von anwendungsspezifischen Dokumentinhalten in der Transcodierungsumgebung mit Hilfe von Java Server Pages. Diese Technik beinhaltet weiterhin folgende Schritte: Abfragen eines JSP-Eingabedokuments, das eine Antwort auf eine Benutzeranforderung darstellt, wobei das Eingabedokument eine oder mehrere Transcodierungsdirektiven festlegt, und Ausführen einer JSP-Engine zum Abarbeiten der Transcodierungsdirektiven. Das Ausführen der JSP-Engine umfasst vorzugsweise folgende Schritte: Lokalisieren der Transcodierungsdirektiven im Eingabedokument, wobei jede der lokalisierten Transcodierungsdirektiven ein oder mehrere überschreibende Schlüsselwort/Wert-Paare enthält; Festlegen eines Zielkontexts für die Benutzeranforderung, wobei der Zielkontext ein oder mehrere überschreibende Schlüsselwort/Wert-Paare enthält; Vergleichen jedes überschreibenden Schlüsselwort/Wert-Paares mit den entsprechenden Schlüsselwort/Wert-Paaren des Kontexts; und Ersetzen eines Kontextwertes aus einem der ausgewählten Schlüsselwort/Wert-Paare des Kontexts durch einen überschreibenden Wert aus einem der ausgewählten überschreibenden Schlüsselwort/Wert-Paare, wenn das ausgewählte Kontextpaar und das ausgewählte überschreibende Paar einen übereinstimmenden Schlüsselwortwert aufweisen. Nach dem Ausführen der JSP-Engine werden die geänderten Schlüsselwort/Wert-Paare des Kontexts zum Erzeugen einer angepassten Ausgabeversion des Eingabedokuments verwendet.

Die Verwendung der Schlüsselwort/Wert-Paare des Kontexts kann außerdem das Ausführen eines Transcodierungsfilters einschließen. Das Eingabedokument kann weiterhin einen oder mehr Transcodierungshinweise enthalten, und die Technik kann zudem beinhalten, dass diese Hinweise zur weiteren Verfeinerung der auf den Client zugeschnittenen Ausgabeversion eingesetzt werden. Der Einsatz der Transcodierungshinweise kann außerdem folgende Schritte umfassen: Verwenden der Transcodierungshinweise zum Auswählen einer oder mehrerer geeigneter Formatvorlagen, und Ausführen eines Transcodierungsfilters, der die ausgewählten Formatvorlagen auf das Eingabedokument anwendet. Der Einsatz der Transcodierungshinweise kann außerdem noch folgende Schritte umfassen: Verwenden der Transcodierungshinweise und der durch das Überschreiben geänderten Schlüsselwort/Wert-Paare des Kontexts, um eine oder mehrere geeignete Formatvorlagen auszuwählen, und Ausführen eines Transcodierungsfilters, der die ausgewählten Formatvorlagen auf das Eingabedokument anwendet. Die Formatvorlagen können in Form einer XSL-Notation definiert werden.

Die vorliegende Erfindung wird nun anhand der folgenden Figuren beschrieben, deren Elemente im Folgenden stets gleich durchnummeriert sind.

KURZBESCHREIBUNG DER FIGUREN

Fig. 1 stellt in Form eines Blockdiagramms eine Arbeitsplatzrechnerumgebung dar, in der die vorliegende Erfindung eingesetzt werden kann.

Fig. 2 ist eine schematische Darstellung einer Netzwerkumgebung, in der die vorliegende Erfindung eingesetzt werden kann.

Fig. 3 veranschaulicht in Form eines Ablaufdiagramms die Logik, mit der eine JSP-Engine gemäß der bevorzugten Ausführung der vorliegenden Erfindung erweitert werden kann.

Fig. 4 veranschaulicht in Form eines Ablaufdiagramm die Logik, mit der eine Transcodierungs-Engine die anwendungsspezifischen Merkmale verwendet, durch die gemäß der bevorzugten Ausführung der vorliegenden Erfindung die Auswahl der Formatvorlagen erfolgt.

Fig. 5 stellt ein einfaches, durch die Ausführung einer JSP erzeugtes Ausgabedokument dar, wobei dieses Ausgabedokument Anwendungsmerkmale enthält, die gemäß der vorliegenden Erfindung eingefügt wurden.

Fig. 6 stellt ein Beispiel für ein Ausgabedokument dar, das gemäß der vorliegenden Erfindung durch einen Transcodierungsfilter unter Verwendung der anwendungsspezifischen Merkmalsinformationen erzeugt wurde und an dem eine detailliertere anwendungsspezifische Transformation vorgenommen wurde als dies nach dem bisherigen Stand der Technik möglich war.

BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNG

Fig. 1 zeigt eine repräsentative Hardwareumgebung eines Arbeitsplatzrechners, in der die vorliegende Erfindung eingesetzt werden kann. Die in Fig. 1 dargestellte Umgebung umfasst einen einzelnen Arbeitsplatzrechner 10, beispielsweise einen PC, und an diese angeschlossene Peripheriegeräte. Zum Arbeitsplatzrechner 10 gehören ein Mikroprozessor 12 und ein Bus 14, der mit Hilfe bekannter Techniken die Kommunikation zwischen dem Mikroprozessor 12 und den Komponenten des Arbeitsplatzrechners 10 aufbaut und aktiviert. Der Arbeitsplatzrechner 10 umfasst typischerweise einen Benutzerschnittstellenadapter 16, der den Mikroprozessor 12 über den Bus 14 mit einem oder mehreren Schnittstellengeräten, wie einer Tastatur 18, einer Maus 20 und/oder weiteren Schnittstellengeräten 22 verbindet, bei denen es sich um beliebige Benutzerschnittstellengeräte, wie einen Tastbildschirm, ein Digitalisierungseingabebrett usw. handelt. Über einen Bildschirmadapter 26 verbindet der Bus 14 außerdem ein Anzeigegerät 24, beispielsweise einen LCD-Bildschirm, mit dem Mikroprozessor 12. Der Bus 14 verbindet darüber hinaus den Mikroprozessor 12 mit dem Speicher 28 und dem Langzeitspeicher 30, bei dem es sich beispielsweise um ein Festplatten-, ein Disketten- oder ein Bandlaufwerk handeln kann.

Der Arbeitsplatzrechner 10 kann beispielsweise über einen Kommunikationskanal oder Modem 32 mit anderen Computern oder Computernetzwerken kommunizieren. Stattdessen kann der Arbeitsplatzrechner 10 diese Kommunikation auch über eine drahtlose Schnittstelle 32 wie eine CDPD-Karte (Cellular Digital Packet Data, CDPD) aufbauen. Der Arbeitsplatzrechner 10 kann mit anderen Computern in einem lokalen Netzwerk (Local Area Network, LAN) oder in einem Weitverkehrsnetzwerk (Wide Area Network, WAN) verbunden werden oder in einer Client/Server-Konfiguration mit einem anderen Computer als Client fungieren usw. Alle genannten Konfigurationen sowie die geeignete Kommunikationshardware sowie -software entsprechen dem aktuellen Stand der Technik.

Fig. 2 stellt ein Netzwerk zur Datenverarbeitung 40 dar, in dem die vorliegende Erfindung eingesetzt werden kann. Das Netzwerk zur Datenverarbeitung 40 kann aus einer Vielzahl einzelner Netzwerke wie dem drahtlosen Netzwerk 42 und dem Netzwerk 44 bestehen, an die jeweils wiederum eine Reihe von Arbeitsplatzrechnern 10 angeschlossen sein können. Fachleute wissen zu schätzen, dass zusätzlich noch ein oder mehrere LAN (nicht in der Figur enthalten) in das Netzwerk integriert werden kann, wobei ein LAN sich aus einer Vielzahl intelligenter Arbeitsplatzrechner zusammensetzen kann, die an einen Host-Prozessor gekoppelt sind.

Die in Fig. 2 dargestellten Netzwerke 42 und 44 können zudem noch Großrechner oder Server wie einen Gateway-Computer 46 oder einen Anwendungsserver 47 umfassen (die auf ein Daten- Repository 48 zugreifen können). Ein Gateway-Computer 46 dient als Verbindungspunkt zu den einzelnen Netzwerken 44. Über eine Kommunikationsverbindung 50a kann der Gateway-Computer 46 vorzugsweise an ein anderes Netzwerk gekoppelt werden. Der Gateway-Computer 46 kann über eine Kommunikationsverbindung wie 50b oder 50c außerdem direkt mit einem oder mehreren Arbeitsplatzrechnern 10 verbunden werden. Der Gateway- Computer 46 kann als Enterprise Systems Architecture/370 der International Business Machines Corporation (IBM), als Enterprise Systems Architecture/390 usw. implementiert werden. Je nach Applikation kann als Gateway ein Computer der mittleren Kategorie wie ein Application System/400 (auch als AS/4000 bekannt) eingesetzt werden. ("Enterprise Systems Architecture/370" ist ein Warenzeichen von IBM; "Enterprise Systems Architecture/390", "Application System/400" und "AS/400" sind eingetragene Warenzeichen von IBM.)

Der Gateway-Computer 46 kann auch mit einem Speichergerät (beispielsweise mit einem Daten-Repository 48) verbunden 49 werden. Darüber hinaus kann der Gateway-Computer 46 direkt oder indirekt mit einem oder mehreren Arbeitsplatzrechnern 10 verbunden werden.

Fachleute werden zu schätzen wissen, das der Gateway- Computer 46 eine große geographische Distanz zum Netzwerk 42 aufweisen kann, und dass in ähnlicher Weise die Arbeitsplatzrechner 10 ihren Standort in beträchtlicher Entfernung zu den Netzwerken 42 und 44 haben können. Der Standort des Netzwerks 42 kann beispielsweise in Kalifornien sein, während der Gateway-Computer 46 in Texas steht und einer oder mehrere der Arbeitsplatzrechner 10 sich in New York befinden. Die Arbeitsplatzrechner 10 können beispielsweise durch das Netzwerkprotokoll TCP/IP (Transmission Control Protocol/Internet Protocol) durch eine Reihe alternativer Verbindungsmedien wie z. B. Mobiltelefonen, Hochfrequenz- Netzwerken oder Satellitennetzwerke mit dem drahtlosen Netzwerk 42 verbunden werden. Das drahtlose Netzwerk 42 ist vorzugsweise durch eine Netzwerkverbindung 50a wie TCP oder das Anwender-Daten-Protokoll UDP (User Datagram Protocol) und durch die Datenübertragung beispielsweise per IP, X.25, Frame Relay, ISDN (Integrated Services Digital Network) oder PSTN (Public Switched Telephone Network) an den Gateway-Computer 46 gekoppelt. Die Arbeitsplatzrechner 10 können stattdessen durch Wählverbindungen wie 50b oder 50c direkt mit dem Gateway- Computer 46 verbunden werden. Darüber hinaus können das drahtlose Netzwerk 42 und das Netzwerk 44 auf die in Fig. 2 dargestellte Weise an ein oder mehrere weitere Netzwerke (nicht dargestellt) angebunden werden.

Der im Mittelpunkt der vorliegenden Erfindung stehende Softwareprogrammierungscode ist auf Langzeitspeichergeräten wie einem CD-ROM-Laufwerk oder einem Festplattenlaufwerk gespeichert, auf die typischerweise von dem Mikroprozessor 12 eines Servers wie Server 47 oder eines Vermittlungspunkts wie dem Gateway-Computer 46 (im Folgenden vereinfachend als Vermittler bezeichnet) zugegriffen wird. Der Softwareprogrammierungscode kann auf einem beliebigen bekannten Datenträger enthalten sein, der für die Verwendung in einem Datenverarbeitungssystem vorgesehen ist. Dabei kann es sich beispielsweise um eine Diskette, eine Festplatte oder eine CD-ROM handeln. Der Code kann über diese Datenträger übertragen oder von dem Speicher eines Computersystems über ein Netzwerk den Benutzern anderer Netzwerke zur Verfügung gestellt werden. Der Programmierungscode kann als Alternative auch im Speicher 28 enthalten sein, sodass der Zugriff auf den Code durch den Mikroprozessor 12 über den Bus 14 erfolgt. Die Techniken und Verfahren, um Softwareprogrammierungscodes in einem Speicher abzulegen, über physikalische Medien zu transportieren und/oder über Netzwerke zu übertragen, sind allgemein bekannt und werden im Folgenden nicht weiter behandelt.

Ein Anwender der vorliegenden Erfindung kann seinen Computer über eine Kabelverbindung oder über eine drahtlose Verbindung an einen Server anschließen. Kabelverbindungen bestehen aus physikalischen Medien wie Kabel und Telefonleitungen, während drahtlose Verbindungen Medien wie Satellitenverbindungen, Hochfrequenzwellen und Infrarotstrahlen nutzen. Diese verschiedenen Medien ermöglichen den Einsatz einer Vielzahl von Verbindungstechniken. Hierzu zählen die Verwendung eines Modems zum Aufbau einer Verbindung über eine Telefonleitung, die Verwendung einer LAN-Karte wie Token Ring oder Ethernet, die Verwendung eines Modems für das Mobilfunknetz zum Aufbau einer drahtlosen Verbindung usw. Bei dem Computer des Anwenders kann es sich um einen beliebigen Rechner handeln, der über Datenverarbeitungs- und Kommunikationsfunktionen (optional) verfügt. Dazu zählen beispielsweise Laptops, Handheld-PCs oder mobile Computer sowie Bordcomputer, Desktop- PCs, Großrechner usw. Als Fernserver und Vermittler können ebenfalls verschiedene Computertypen eingesetzt werden, die über Datenverarbeitungs- und Kommunikationsfunktionen verfügen. Die genannten Verbindungstechniken sind allgemein bekannt, und die zu ihrer Nutzung erforderliche Hardware und Software ist verfügbar. Im Folgenden wird der Computer des Benutzers gleichbedeutend als "Arbeitsplatzrechner", "Gerät" oder "Computer" bezeichnet, und die Verwendung eines dieser Begriffe oder des Begriffs "Server" bezieht sich auf alle der oben genannten Rechnertypen.

In der bevorzugten Ausführung wird die vorliegende Erfindung in Form eines oder mehrerer Softwareprogramme implementiert. Die Software kann entweder gänzlich auf einem Anwendungsserver installiert sein oder zu einem Teil auf einem Anwendungsserver und zum anderen Teil auf einem Vermittler in einem Netzwerk in Form eines oder mehrerer Module (so genannte Subroutinen oder "Objekte" in der objektorientierten Programmierung) zum Einsatz kommen, die auf Anforderung aufgerufen werden. Zur Vereinfachung der Benennung wird mit dem Begriff "Server" im Folgenden jedes der beiden genannten Geräte als dasjenige bezeichnet werden, auf dem vor dem Verschicken eines Dokuments an einen Client der Transcodierungsvorgang durchgeführt wird. Der Anwendungsserver und der Vermittler können Dienste in einer Internetumgebung, in einem firmeneigenen Intra- oder Extranet sowie in beliebigen anderen Netzwerkumgebungen bereitstellen.

Die vorliegende Erfindung definiert eine neuartige Technik, die einem Autor von JSP-basierten Anwendungen die Festlegung anwendungsspezifischer Merkmale ermöglicht, die gewährleisten, dass ein Transcoder ein Ausgabedokument genauer auf den jeweiligen Empfänger zuschneiden kann. Der Transcodierungsprozess kann auf einem Anwendungsserver ablaufen, der das angeforderte Dokument verarbeitet, oder auf einem Vermittler in der Lieferkette zwischen dem gespeicherte Daten anfordernden Client und der Serveranwendung, die die angeforderten Informationen abgerufen hat. Vermittler führen anhand der Merkmale der Eingabeanforderungsquelle üblicherweise verschiedene Übersetzungs- und/oder Transformationsvorgänge durch. XML ist beispielsweise ein weithin anerkannter Industriestandard für das Publizieren und Austauschen von Daten mit Hilfe von Netzwerken wie dem Internet. Bei der Übertragung von Daten in Form eines XML- Dokuments muss dieses durch einen herkömmlichen Übersetzungsvorgang in eine andere Markierungssprache umformatiert werden, wobei die Zielmarkierungssprache besser auf den Zielkontext abgestimmt ist. Für den Fall, dass der anfordernde Benutzer von seinem Mobiltelefon Daten über eine drahtlose Verbindung angefordert hat, umfasst der Zielkontext die Identifizierung des Benutzers, sein in der Funktionalität eingeschränktes Gerät, die drahtlose Netzwerkverbindung sowie den Browser oder die entsprechende Anwendungssoftware, über die der Benutzer seine Anforderung getätigt hat. Für dieses Beispiel kann festgelegt werden, dass der Browser des Benutzers nicht XML sondern WML ("Wireless Markup Language") unterstützt. Bei WML handelt es sich um eine für Benutzer von drahtlosen Rechnern entwickelte XML-Version zur Präsentation von Dokumenten. Infolgedessen führt der Vermittler eine Übersetzung von XML in WML durch und sendet das so entstandene WML-Dokument an den anfordernden Benutzer. Ein typisches Verfahren zur Ausführung dieser Übersetzung sowie einer Vielzahl weiterer Übersetzungs- und Transformationsvorgänge besteht im Anwenden einer Formatvorlage auf das Eingabedokument.

In der Referenzerfindung wurde eine Technik beschrieben, mit der ein Dokumentinhalt auf seinen Zielkontext zugeschnitten werden kann. Dies geschieht durch den Einsatz einer oder mehrerer besonderer Formatvorlagen, durch die an einem bestimmten Satz von Merkmalen der Eingabeanforderungsquelle ein geeigneter Transformationsvorgang durchgeführt wird. Die Referenzerfindung enthält die Definition einer Technik zum Verknüpfen von Merkmalen mit Formatvorlagen. Dies geschieht durch das Deklarieren eines Satzes von Schlüsselwort/Wert- Paaren, das Einspeisen dieser Paare in eine Suchmaschine und das Abfragen einer geeigneten Formatvorlage durch Festlegung eines Musters, das eines oder mehrere der Merkmale enthält. Die in der Referenzerfindung dargestellte Technik ist in dem vorliegenden Dokument als Referenz enthalten und wird vorzugsweise mit der vorliegenden Erfindung eingesetzt. Indem diese Handhabung der Merkmale der Eingabeanforderungsquelle (wie in der Referenzerfindung definiert) auf anwendungsspezifische Merkmale (wie in der vorliegenden Erfindung definiert) übertragen wird, können dieselben, in der Referenzerfindung definierten Mechanismen von der Transcodierungs-Engine verwendet werden, um sowohl anhand der Merkmale der Eingabeanforderung als auch anhand der vom JSP- Autor festgelegten anwendungsspezifischen Merkmale einen Transformationsvorgang auszuwählen.

In dem vorliegenden Dokument werden zwei neuartige Techniken vorgestellt, die dem JSP-Autor die Festlegung von anwendungsspezifischen Informationen ermöglichen, durch die er die Erzeugung der Ausgabeseiten durch seine Anwendung genauer steuern kann. Die erste Technik wird in dem vorliegenden Dokument als "Transcodierungsdirektive" bezeichnet. Die JSP- Sprache ist durch mehrere Direktiven definiert. Dazu zählen eine "Einschlussdirektive" und eine "Seitendirektive". Der Gebrauch der Bezeichnung "Direktive" impliziert, das die JSP- Verarbeitungs-Engine angewiesen wird, eine bestimmte Aufgabe auszuführen. Durch die Transcodierungsdirektive der vorliegenden Erfindung wird diese Liste vordefinierter Direktiven erweitert. Über die Transcodierungsdirektive wird die JSP-Engine angewiesen, die verknüpfte Eingabe für die spätere Verwendung durch einen Transcodierungsfilter zu bearbeiten. Dies wird ausführlich in den nachfolgenden Erläuterungen zu Fig. 3 beschrieben. Die zweite Technik wird in dem vorliegenden Dokument entsprechend als "anwendungsspezifische Markierung" oder als "Transcodierungshinweise" bezeichnet. Ein Transcodierungshinweis besteht aus Informationen, die durch das Ausführen einer JSP in ein Dokument eingefügt werden, wo sie nachfolgend von einem Transcodierungsfilter abgearbeitet werden. Die Art und Weise wie ein Transcoder gemäß der vorliegenden Erfindung Transcodierungshinweise abarbeitet, wird weiter unten in den Erläuterungen zu Fig. 4 erklärt.

Die bevorzugte Ausführung der Syntax für eine Transcodierungsdirektive entspricht der Syntax für bereits vorhandene Direktiven in der JSP-Sprache. Bei der Verwendung von HTML muss dabei dem Namen der Direktive die Syntax "<%@" vorangestellt werden, und der Parameterliste der Direktive muss die Syntax "%<" nachgestellt werden. Bei der Verwendung von XML muss dem Namen der Direktive die Syntax "<jsp:directive." vorangestellt werden und das abschließende Begrenzungssteuerzeichen "/<" muss nachgestellt werden. Die in einer HTML-Seite codierte Syntax einer Transcodierungsdirektive lautete somit wie folgt:
<%@transcode [transcoding directive parameter list]%<
Die Parameterliste wird vorzugsweise als Schlüsselwort/Wert- Paar definiert. Dabei ist jedes Schlüsselwort von dem ihm zugeordneten Wert durch ein Gleichheitszeichen ("=") getrennt, der Wert ist in doppelte Anführungszeichen eingeschlossen, und die einzelnen Paare sind durch Leerschritte als Begrenzungszeichen voneinander getrennt. Die in einer XML- Seite codierte Syntax einer Transcodierungsdirektive lautete wie folgt:
<jsp:directive.transcode [transcoding directive parameter list] /<

Es ist zu beachten, dass im Sinne der vorliegenden Erfindung diese Syntax durch die JSP-Engine (siehe Fig. 3) bearbeitet werden muss.

Die Transcodierungsdirektive hat die Funktion, dem JSP-Autor das Ändern eines oder mehrerer der Merkmale der Eingabequellenanforderung zu ermöglichen. Die Merkmale der Eingabequelle sind typischerweise den Kopffeldern der HTTP- Anforderung zu entnehmen, mit der die Seite angefordert wurde. Der JSP-Autor möchte eventuell einen oder mehrere dieser Werte an die Bedingungen seiner Anwendung anpassen und verwendet dazu Werte, die er mit Blick auf die von seiner Anwendung ausgeführten Verarbeitungsprozesse selbst auswählt. Als Beispiel für das Ändern eines Merkmals der Eingabeanforderungsquelle, kann die Syntax
<%@transcode user = "guest@www.ibm.com"%<
von dem JSP-Autor in eine JSP-Seite codiert werden, um darauf hinzuweisen, dass die Benutzeridentität zwingend in "guest@www.ibm.com" (an Stelle der von der Eingabeanforderung abgeleiteten Identität) geändert werden muss, wenn das von der JSP-Anwendung erzeugte HTML-Dokument einen Transcodierungsfilter durchläuft. Die entsprechende Syntax für eine XML-Seite lautete wie folgt:
<jsp:directive.transcode user = "guest@www.ibm.com"/<
Diese Überschreibtechnik kann auf alle Merkmale der Eingabeanforderungsquelle angewendet werden.

Die bevorzugte Ausführung der Syntax für einen Transcodierungshinweis umfasst zudem eine Syntax für HTML und eine weitere für XML, um auf die jeweilige Syntax der Sprachen abgestimmt zu sein. Für die Abarbeitung der Transcodierungshinweise ist ein Transcodierungsfilter vorgesehen. Wie bereits erwähnt, kann der Transcodierungsfilter in der JSP-Engine enthalten oder Teil eines Vermittlers im Netzwerk sein, der das von der JSP-Engine erzeugte Dokument empfängt und anschließend transcodiert. In Anbetracht dieser möglichen Anordnung des Transcoders im Netzwerk, muss die Syntax der Transcodierungshinweise in der Lage sein, andere Vermittler im Netzwerkpfad als gültige Dokumentmarkierung zu passieren. (D. h., dass die Syntax von den Vermittlern im Pfad als gültig erkannt werden muss, bevor sie den Transcodierungsfilter erreicht - nach der Verarbeitung durch den Filter sind die Markierungen für die Transcodierungshinweise gelöscht.) Infolgedessen besteht die bevorzugte Ausführung zum Einfügen eines Transcodierungshinweises in ein HTML-Dokument in der Überladung der Kommentarsyntax, sodass die Transcodierungshinweise folgende Form aufweisen:
<!--@ transcode [application characteristic list] --<

Wie die Parameterliste der Transcodierungsdirektiven wird auch die Parameterliste der Transcodierungshinweise vorzugsweise als Schlüsselwort/Wert-Paare festgelegt. Dabei ist jedes Schlüsselwort von dem ihm zugeordneten Wert durch ein Gleichheitszeichen ("=") getrennt, der Wert ist in doppelte Anführungszeichen eingeschlossen, und die einzelnen Paare sind durch Leerschritte als Begrenzungszeichen voneinander getrennt. Die bevorzugte Ausführung der Syntax zum Codieren eines Transcodierungshinweises in einer XML-Seite lautet wie folgt:
<suggestion:transcode [transcoding directive parameter list] /<

Die Funktion eines Transcodierungshinweises besteht nicht darin, ein Eingabemerkmal zu überschreiben, sondern vielmehr darin, Anwendungsmerkmale anzubieten, die neben Eingabemerkmalen bei der Auswahl einer geeigneten Formatvorlage für den Transcodierungsprozess verwendet werden können. Anhand der Bedingungen jeder einzelnen Anwendung wird wie im Falle der Transcodierungsdirektive festgelegt, welche Transcodierungshinweise in einem zu transcodierenden Dokument geeignet sind. Folglich kann der JSP-Autor je nach seiner Kenntnis des gerade erzeugten Dokuments Hinweise festlegen und definieren, wie eine Formatvorlage das Ausgabedokument optimal auf den Client zuschneiden kann. Zum Festlegen eines Transcodierungshinweises könnte der JSP-Autor beispielsweise einen Code schreiben, um in das durch seine Anwendung erzeugte HTML-Dokument die folgende Syntax einzufügen:
<!--@ transcode reportstyle = "catalog"--<

Dies weist darauf hin, dass der Transcoder dieses Dokument am besten durch den Einsatz einer XSL-Formatvorlage wiedergibt, die über das gleiche Merkmalsattribut reportstyle = "catalog" verfügt. Die entsprechende Syntax für eine XML-Seite lautete wie folgt:
<suggestion:transcode reportstyle = "catalog" /<

Anhand der Fig. 3 bis 6 wird die bevorzugte Ausführung der vorliegenden Erfindung im Folgenden näher erläutert. An einem einfachen Beispiel werden die Vorteile und die Implementierung der vorliegenden Erfindung veranschaulicht.

Fig. 3 veranschaulicht die Logik, mit der eine JSP-Engine erweitert werden kann, um Transcodierungsdirektiven gemäß der bevorzugten Ausführung zu verarbeiten. Wie in der Technik bekannt ist, wird der von der JSP-Engine ausgeführte Verarbeitungsvorgang gestartet, nachdem ein Client ein bestimmtes Web-Dokument angefordert hat, und wenn sich das angeforderte Dokument (bei dem es sich um eine Java Server Page handelt) auf dem Webserver befindet, der die Anforderung des Clients beantwortet. Fig. 3 beschreibt nicht die vorhandene Logik der JSP-Engine, sondern vielmehr die Erweiterungen, die vorzugsweise für die vorliegende Erfindung verwendet werden. Für Fachleute ist es offensichtlich, wie diese neuartigen Erweiterungen in den logischen Fluss einer vorhandenen JSP-Engine integriert werden können. Der Prozess setzt bei Block 300 ein, wo die JSP-Engine eine Anweisung von der Java Server Page liest. Block 305 fragt, ob durch diese Anweisung eine Verarbeitungsdirektive festgelegt wird. Ist dies der Fall, fragt Block 310, ob es sich um eine Transcodierungsdirektive der vorliegenden Erfindung handelt. Wenn es sich bei der Anweisung weder um eine Verarbeitungsdirektive ("Nein" bei Block 305) noch um eine Transcodierungsdirektive ("Nein" bei Block 310) handelt, geht die Steuerung des Vorgangs auf Block 320 über, und die Anweisung wird nach dem bisherigen Stand der Technik abgearbeitet.

Handelt es sich bei der Anweisung um eine Transcodierungsdirektive, wird diese durch Block 315 verarbeitet. Block 315 lokalisiert vorzugsweise das Schlüsselwort aus der Transcodierungsdirektive und ermittelt dann, ob in den Merkmalen der Eingabequelle ein passendes Schlüsselwort enthalten ist. Wird ein solches Schlüsselwort in der Eingabequelle gefunden, wird der aus der Eingabequelle stammende Wert durch den vom JSP-Autor für die Transcodierungsdirektive festgelegten Wert überschrieben. Wird das Schlüsselwort durch die von Block 315 ausgeführten Verarbeitungsprozesse nicht gefunden, können das Schlüsselwort und der zugehörige Wert aus der Transcodierungsdirektive einfach in einer Liste überschreibender Wertepaare gespeichert werden, wobei der tatsächliche der eigentliche Überschreibungsvorgang (d. h., das Lokalisieren des Schlüsselwortes in den Merkmalen der Eingabequelle und das Ersetzen des zugehörigen Wertes) erst zu einem späteren Zeitpunkt des Verarbeitungsablaufes stattfindet, wenn die Frage in Block 325 mit "Ja" beantwortet wird.

Nach der Abarbeitung der von Block 300 gelesenen Eingabeanweisung wird Block 325 im Ablauf erreicht. Block 325 prüft nun, ob es sich bei der Anweisung um die letzte Anweisung in der JSP gehandelt hat. Ist dies nicht der Fall, geht die Steuerung des Ablaufs wieder auf Block 300 über, damit der Verarbeitungsprozess für die nächste Anweisung wiederholt werden kann. Andernfalls hat Block 325 bei Erreichen des Eingabedateiendes ein positives Ergebnis ermittelt, und der Verarbeitungsprozess wird bei Block 330 fortgesetzt.

Bei Erreichen von Block 330 im Ablauf wurde das Ausgabedokument bereits durch die JSP-Engine erzeugt. Sämtliche Transcodierungsdirektiven der Java Server Page wurden lokalisiert und abgearbeitet. Alle vom JSP-Autor festgelegten Transcodierungshinweise wurden in das erzeugte Ausgabedokument eingefügt. (Es ist zu beachten, dass an der JSP-Engine keine Änderungen vorgenommen werden müssen, um das Schreiben der Transcodierungshinweise in das Dokument zu ermöglichen. Zu diesem Zweck können bereits vorhandene "Schreiboperationen" verwendet werden.) Die JSP-Engine prüft in Block 330, ob ein geeigneter Transcodierungsfilter lokal verfügbar ist. (Mit Hilfe der Verfahren auf dem bisherigen Stand der Technik können Transcodierungs- und andere Ausgabefilter zusammen mit der Serversoftware registriert werden. Folglich kann Block 330 implementiert werden, indem geprüft wird, ob ein solcher Filter vorhanden ist.) Ist dies der Fall, wird der Transcoder in Block 335 aufgerufen, um die Zielkontextinformationen (mit den bei der Verarbeitung durch Block 315 überschriebenen Werten) und das von der JSP erzeugte Dokument weiterzuleiten. Die Ausgabe der lokalen Transcodierungsoperation (hierbei handelt es sich um ein Dokument, das keine Transcodierungshinweise mehr enthält, da diese vom lokalen Transcoder verarbeitet und gelöscht wurden) wird anschließend zum Netzwerk weitergeleitet, um an den anfordernden Client in Block 340 übermittelt zu werden. (Eine Beschreibung der Transcodierungsoperation enthält Fig. 4.) Steht kein lokaler Transcodierungsfilter zur Verfügung, kann Block 345 das von der JSP erzeugte Dokument (das möglicherweise Transcodierungshinweise enthält) an das Netzwerk weitergeleitet werden, um dort durch einen netzwerkeigenen Filter (siehe Fig. 4) bearbeitet zu werden. Stattdessen kann Block 345 die Überschreibungsinformationen für den Zieltext (in Form der durch Block 315 verarbeiteten Markierungen "<%@ transcode" bzw. "jsp:directive.transcode") auch einfach in das erzeugte Dokument (das ebenfalls Transcodierungshinweise enthalten kann) einfügen, bevor das resultierende Dokument in das Netzwerk gesandt wird. Der in Fig. 3 dargestellte Verarbeitungsablauf ist zu Ende, wenn die Verarbeitungsvorgänge von Block 340 bzw. von Block 345 abgeschlossen sind.

Fig. 4 veranschaulicht die Logik, mit der ein Transcodierungsfilter (entweder bei einem Vermittler in einem Netzwerk oder bei der JSP-Engine) die überschriebenen Kontextinformationen und Transcodierungshinweise der vorliegenden Erfindung zum Erzeugen eines Dokuments nutzt, an dem eine detailliertere anwendungsspezifische Transformation vorgenommen wurde als dies nach dem bisherigen Stand der Technik möglich war. Der Prozess setzt bei Block 400 ein. An dieser Stelle wird die mit dem gerade transcodierten Eingabedokument (d. h., das durch die JSP-Engine erzeugte Dokument einschließlich aller Änderungen, die sich nach dem Ablauf des in Fig. 3 dargestellten logischen Prozesses ergeben haben) verknüpfte Dokumentartdefinition (DTD) auf die auf dem bisherigen Stand der Technik üblichen Weise abgefragt. Block 405 durchsucht anschließend das Eingabedokument nach Transcodierungshinweisen. Wenn der Transcodierungsfilter in einem Netzwerk angeordnet ist, umfasst dieser Prozess zudem das Durchsuchen des Eingabedokuments nach Markierungen zum Überschreiben des Zielkontexts (die möglicherweise während des von Block 345 durchgeführten Verarbeitungsprozesses in das Dokument eingefügt wurden). Die bei diesem Durchsuchungsvorgang lokalisierten Schlüsselwörter und Werte werden anschließend in Block 410 den als Eingabe empfangenen Zielkontextinformationen hinzugefügt. Alle von einem in das Netzwerk integrierten Transcodierungsfilter in Block 405 erkannten Überschreibungsmarkierungen werden zudem an diesem Punkt zum Überschreiben der entsprechenden Zielkontextwerte verwendet (wie weiter oben in den Erläuterungen zu Block 315 beschrieben). In Block 415 wird aus dem Verarbeitungsergebnis von Block 410 eine Suchzeichenfolge für die Suche nach einem Repository gespeicherter Formatvorlagenmerkmalen erzeugt. Dazu wird vorzugsweise der in der Referenzerfindung definierte Ansatz verwendet. Die abgefragten Formatvorlagen werden daraufhin gemäß dem bisherigen Stand der Technik von einer XSL-Engine angewendet. Der in Fig. 4 dargestellte Verarbeitungsprozess ist damit abgeschlossen, und das anhand der von dem JSP-Autor festgelegten anwendungsspezifischen Merkmale zugeschnittene Dokument wird auf dem Lieferpfad an den anfordernden Client geschickt.

Die Fig. 5 und 6 enthalten Beispieldokumente, die der weiteren Veranschaulichung der in der bevorzugten Ausführung der vorliegenden Erfindung ablaufenden Verarbeitungsprozesse dienen. Fig. 5 stellt die Ausgabe einer JSP dar, durch die HTML-Syntax erzeugt wird. Da die Transcodierungsdirektiven gemäß den in Fig. 3 geschilderten Verarbeitungsvorgängen gelöscht wurden, sind in diesem JSP-Ausgabedokument lediglich die enthaltenen Transcodierungshinweise dargestellt. Das Beispieldokument 500 ging aus einer von Banken genutzten Anwendung hervor, bei der die Kontodaten eines Bankkunden abgerufen und für die Anzeige durch einen Browser formatiert wurden. In diesem Beispiel hat die JSP ein Dokument erzeugt, das neben den Kontoständen des Kunden und anderen Informationen (als Element 530 dargestellt) ein Formular 520 für die Auswahl der Zahlungsweise enthält. Der Transcodierungshinweis 510 verwendet die bereits zuvor beschriebene kommentarartige Markierung für HTML-Dokumente. In diesem Transcodierungshinweis 510 hat das Schlüsselwort "contour" 511 den Wert "h2+body" 512. In diesem hypothetischen Beispiel entspräche dies einem Schlüsselwort/Wert-Paar, das mit einer Formatvorlage verknüpft ist, die ein Dokument so partitioniert, dass jede Überschrift der zweiten Ebene als eine abgeschlossene Informationseinheit behandelt wird. Weiterhin ist in dem Transcodierungshinweis 510 dem Schlüsselwort "transaction" 513 der Wert "hasform" 514 zugeordnet, damit eine geeignete Formatvorlage für die Bearbeitung von Dokumentseiten ausgewählt werden kann, die Anforderungen für Benutzereingaben enthalten (d. h., das auf dieser HTML-Seite im Bereich 520 definierte Formular).

Die Fig. 6 enthält ein Beispielausgabedokument 600, das erzeugt werden kann, nachdem der auf das Dokument 500 angewendete Transcodierungsfilter (bzw. die auf das Dokument 500 angewendeten Transcodierungsfilter) die HTML- Syntax in eine WML-Syntax konvertiert hat (beispielsweise nachdem über den Zielkontext festgestellt wurde, dass der anfordernde Benutzer einen Pager oder ein Bildschirmtelefongerät verwendet und an ein drahtloses Netzwerk angeschlossen ist) und zudem die Hinweise "contour" und "hasform" zur Formatierung des an den Kunden zu übermittelnden Dokuments verwendet wurden. Das Eingabeformular 520 wurde durch die Formatvorlage in die WML- Syntax konvertiert, damit es Benutzereingaben (Element 610) annehmen kann, und jede Überschrift der zweiten Ebene (540, 541, 542, 543, 544) des HTML-Dokuments wurde in dem WML- Kartensatz 600 in eine getrennte Karte (620, 621, 622, 623 bzw. 624) konvertiert.

Wie bisher demonstriert wurde, bietet die vorliegende Erfindung Techniken, die für einen JSP-Autor den Vorteil haben, dass er das von seiner Anwendung erzeugte Ausgabedokument anhand anwendungsspezifischer Merkmale genauer auf den jeweiligen Empfänger zuschneiden kann. Die vorliegende Erfindung ermöglicht dem JSP-Autor insbesondere, die Merkmale der Eingabequellenanforderung zu überschreiben und Transcodierungshinweise festzulegen, die von einem Transcodierungsfilter für die Auswahl einer geeigneten Formatvorlage verwendet werden. Die Transcodierungshinweise, die möglicherweise Vermittler im Netzwerk passieren müssen, sind in einer abwärtskompatiblen Syntax erstellt, sodass vorhandene Dokumentprozessoren die Hinweise einfach ignorieren.

Obgleich in der Beschreibung der bevorzugten Ausführung der Einsatz von XSL-Formatvorlagen vorgesehen ist, können auch Formatvorlagen in anderen Notationen als XSL verwendet werden (beispielsweise die sogenannte DSSL - Document Style Semantics and Specification Language - die dem Internationalen Standard ISO/IEC 10179: 1996 entspricht), ohne dass dadurch von den Konzepten der vorliegenden Erfindung abgewichen wird. Gleiches gilt für die in dem vorliegenden Dokument zur Anwendung auf HTML- und XML-Dokumente definierte Syntax für Transcodierungsdirektiven und anwendungsspezifische Markierungen, da diese Syntax ebenfalls auf Dokumente angewendet werden kann, die in anderen Notationen codiert wurden, die eine ähnliche Semantik aufweisen.

Fachleuten, die das Grundkonzept der in diesem Dokument beschriebenen bevorzugten Ausführung der vorliegenden Erfindung erfasst haben, können sich möglicherweise zusätzliche Variations- und Änderungsmöglichkeiten der Ausführung erschließen. Aus diesem Grund sind die im Anhang aufgeführten Ansprüche absichtlich so formuliert, dass diese sowohl die bevorzugte Ausführung als auch die im Sinne und im Rahmen der Erfindung möglichen Variationen und Änderungen beinhalten.

Claims (18)

1. Computerprogramm, das auf einem computerlesbaren Datenträger gespeichert und in einer Datenverarbeitungsumgebung von einem Computersystem lesbar ist, zum Erzeugen eines anwendungsspezifischen Dokumentinhalts mit Hilfe von Java Server Pages, das umfasst:
computerlesbaren Programmcode zum Abrufen eines auf Java Server Pages (JSP) basierenden Eingabedokuments, das eine Antwort auf eine Benutzeranforderung darstellt, wobei das Eingabedokument eine oder mehrere Transcodierungsdirektiven festlegt;
computerlesbaren Programmcode für die Ausführung einer JSP-Engine zum Abarbeiten einer oder mehrerer Transcodierungsdirektiven, wobei die JSP-Engine zudem umfasst:
computerlesbaren Programmcode zum Lokalisieren einer oder mehrerer Transcodierungsdirektiven in dem Eingabedokument, wobei jede der lokalisierten Transcodierungsdirektiven ein oder mehrere überschreibende Schlüsselwort/Wert-Paare enthält;
computerlesbaren Programmcode zum Festlegen eines Zielkontexts der Benutzeranforderung, wobei der Zielkontext ein oder mehrere Schlüsselwort/Wert-Paare enthält;
computerlesbaren Programmcode zum Vergleichen jedes einzelnen überschreibenden Schlüsselwort/Wert-Paars mit den Schlüsselwort/Wert-Paaren des Kontexts; und
computerlesbaren Programmcode zum Ersetzen eines Kontextwertes aus einem ausgewählten Paar der Schlüsselwort/Wert-Paare des Kontexts durch einen überschreibenden Wert aus einem ausgewählten Paar der überschreibenden Schlüsselwort/Wert-Paare, wenn das ausgewählte Kontextpaar und das ausgewählte überschreibende Paar einen übereinstimmenden Schlüsselwortwert aufweisen; und
computerlesbaren Programmcode, um die durch den computerlesbaren Programmcode für den Ersetzungsvorgang geänderten Schlüsselwort/Wert-Paare zum Erzeugen einer angepassten Ausgabeversion des Eingabedokuments zu verwenden.

2. Computerprogramm gemäß Anspruch 1, wobei der computerlesbare Programmcode zum Verwenden der Schlüsselwort/Wert-Paare des Kontexts zudem einen computerlesbaren Programmcode zum Ausführen eines Transcodierungsfilters enthält.

3. Computerprogramm gemäß Anspruch 1, wobei das Eingabedokument zudem einen oder mehrere Transcodierungshinweise enthält, und wobei das Computerprogramm zudem einen computerlesbaren Programmcode enthält, um die Transcodierungshinweise für eine weitere Verfeinerung der angepassten Ausgabeversion zu verwenden.

4. Computerprogramm gemäß Anspruch 3, wobei der computerlesbare Programmcode zum Anwenden der Transcodierungshinweise zudem umfasst:
computerlesbaren Programmcode, um über die Transcodierungshinweise eine oder mehrere geeignete Formatvorlagen auszuwählen; und
computerlesbaren Programmcode zum Ausführen eines Transcodierungsfilters, der die ausgewählten Formatvorlagen auf das Eingabedokument anwendet.

5. Computerprogramm gemäß Anspruch 3, wobei der computerlesbare Programmcode zum Anwenden der Transcodierungshinweise zudem umfasst:
computerlesbaren Programmcode, um die Transcodierungshinweise und die von dem computerlesbaren Programmcode für den Ersetzungsvorgang geänderten Schlüsselwort/Wert-Paare des Kontexts zum Auswählen einer oder mehrerer geeigneter Formatvorlagen zu verwenden; und
computerlesbaren Programmcode zum Ausführen eines Transcodierungsfilters, der die ausgewählten Formatvorlagen auf das Eingabedokument anwendet.

6. Computerprogramm gemäß Anspruch 4 oder Anspruch 5, wobei die Formatvorlagen in einer XSL-Notation (Extensible Stylesheet Language, XSL) definiert werden.

7. System zum Erzeugen eines anwendungsspezifischen Dokumentinhalts in einer Datenverarbeitungsumgebung mit Hilfe von Java Server Pages, das umfasst:
Mittel zum Abrufen eines JSP-Eingabedokuments, das eine Antwort auf eine Benutzeranforderung darstellt, wobei das Eingabedokument eine oder mehrere Transcodierungsdirektiven festlegt;
Mittel zum Ausführen einer JSP-Engine, die zum Abarbeiten einer oder mehrerer Transcodierungsdirektiven vorgesehen ist, wobei die JSP-Engine zudem umfasst:
Mittel zum Lokalisieren einer oder mehrerer Transcodierungsdirektiven im Eingabedokument, wobei jede der Transcodierungsdirektiven ein oder mehrere ersetzende Schlüsselwort/Wert-Paare enthält;
Mittel zum Festlegen eines Zielkontexts der Benutzeranforderung, wobei der Zielkontext ein oder mehrere Schlüsselwort/Wert-Paare des Kontexts enthält;
Mittel zum Vergleichen jedes einzelnen überschreibenden Schlüsselwort/Wert-Paars mit den Schlüsselwort/Wert-Paaren des Kontexts; und
Mittel zum Ersetzen eines Kontextwertes aus einem ausgewählten Paar der Schlüsselwort/Wert-Paare des Kontexts durch einen überschreibenden Wert aus einem ausgewählten Paar der überschreibenden Schlüsselwort/Wert-Paare, wenn das ausgewählte Kontextpaar und das ausgewählte überschreibende Paar einen übereinstimmenden Schlüsselwortwert aufweisen; und
Mittel, um die durch die Ersetzungseinrichtung geänderten Schlüsselwort/Wert-Paare des Kontexts zum Erzeugen einer angepassten Ausgabeversion des Eingabedokuments zu verwenden.

8. System gemäß Anspruch 7, wobei die Mittel zum Verwenden der Schlüsselwort/Wert-Paare des Kontexts zudem Mittel zum Ausführen eines Transcodierungsfilters umfassen.

9. System gemäß Anspruch 7, wobei das Eingabedokument zudem einen oder mehrere Transcodierungshinweise enthält, und wobei das System zudem Mittel umfasst, um die Transcodierungshinweise für eine weitere Verfeinerung der angepassten Ausgabeversion zu verwenden.

10. System gemäß Anspruch 9, wobei die Mittel zum Anwenden der Transcodierungshinweise zudem umfassen:
Mittel, um mit Hilfe der Transcodierungshinweise eine oder mehrere geeignete Formatvorlagen auszuwählen; und
Mittel zum Ausführen eines Transcodierungsfilters, der die ausgewählten Formatvorlagen auf das Eingabedokument anwendet.

11. System gemäß Anspruch 9, wobei die Mittel zum Anwenden der Transcodierungshinweise zudem umfassen:
Mittel, um mit Hilfe der Transcodierungshinweise und der durch die Ersetzungsmittel geänderten Schlüsselwort/Wert- Paare des Kontexts eine oder mehrere geeignete Formatvorlagen auszuwählen; und
Mittel zum Ausführen eines Transcodierungsfilters, der die ausgewählten Formatvorlagen auf das Eingabedokument anwendet.

12. System gemäß Anspruch 10 oder Anspruch 11, wobei die Formatvorlagen in einer XSL-Notation (Extensible Stylesheet Language, XSL) definiert werden.

13. Verfahren zum Erzeugen eines anwendungsspezifischen Dokumentinhalts in einer Datenverarbeitungsumgebung mit Hilfe von Java Server Pages, das folgende Schritte umfasst:
Abfragen eines JSP-Eingabedokuments, das eine Antwort auf eine Benutzeranforderung darstellt, wobei das Eingabedokument eine oder mehrere Transcodierungsdirektiven festlegt;
Ausführen einer JSP-Engine, die zum Abarbeiten einer oder mehrerer Transcodierungsdirektiven vorgesehen ist, wobei dieser Schritt folgende weitere Schritte einschließt:
Lokalisieren einer oder mehrerer Transcodierungsdirektiven im Eingabedokument, wobei jede der lokalisierten Transcodierungsdirektiven ein oder mehrere überschreibende Schlüsselwort/Wert-Paare enthält;
Festlegen eines Zielkontexts der Benutzeranforderung, wobei der Zielkontext ein oder mehrere Schlüsselwort/Wert-Paare des Kontexts enthält;
Vergleichen jedes einzelnen überschreibenden Schlüsselwort/Wert-Paars mit den Schlüsselwort/Wert- Paaren des Kontexts; und
Ersetzen eines Kontextwertes aus einem ausgewählten Paar der Schlüsselwort/Wert-Paare des Kontexts durch einen überschreibenden Wert aus einem ausgewählten Paar der überschreibenden Schlüsselwort/Wert-Paare, wenn das ausgewählte Kontextpaar und das ausgewählte überschreibende Paar einen übereinstimmenden Schlüsselwortwert aufweisen; und
Verwenden der in dem Ersetzungsschritt geänderten Schlüsselwort/Wert-Paare des Kontexts, um eine angepasste Ausgabeversion des Eingabedokuments zu erzeugen.

14. Verfahren gemäß Anspruch 13, wobei der Schritt zum Verwenden der Schlüsselwort/Wert-Paare des Kontexts zudem den Schritt zum Ausführen eines Transcodierungsfilters einschließt.

15. Verfahren gemäß Anspruch 13, wobei das Eingabedokument zudem einen oder mehrere Transcodierungshinweise enthält, und wobei das Verfahren zudem den Schritt einschließt, die Transcodierungshinweise für eine weitere Verfeinerung der angepassten Ausgabeversion zu verwenden.

16. Verfahren gemäß Anspruch 15, wobei der Schritt zum Anwenden der Transcodierungshinweise zudem folgende Schritte einschließt:
Verwenden der Transcodierungshinweise, um eine oder mehrere geeignete Formatvorlagen auszuwählen; und
Ausführen eines Transcodierungsfilters, der die ausgewählten Formatvorlagen auf das Eingabedokument anwendet.

17. Verfahren gemäß Anspruch 15, wobei der Schritt zum Anwenden der Transcodierungshinweise zudem folgende Schritte einschließt:
Verwenden der Transcodierungshinweise und der durch den Ersetzungsschritt geänderten Schlüsselwort/Wert-Paare des Kontexts, um eine oder mehrere geeignete Formatvorlagen auszuwählen; und
Ausführen eines Transcodierungsfilters, der die ausgewählten Formatvorlagen auf das Eingabedokument anwendet.

18. Verfahren gemäß Anspruch 16 oder Anspruch 17, wobei die Formatvorlagen in Form einer XSL-Notation (Extensible Stylesheet Language, XSL) definiert werden.