|
| | | Fallstudie Lösung zur Bearbeitung von RSS Feeds
Übersicht Als Software-Anbieter, der ständig innovative Lösungen entwickelt, ergänzt Altova seine Website laufend durch Beschreibungen neuer Produktfeatures, Pressemitteilungen, Newsletter, Lösungsbeschreibungen und andere Inhalte. Die Marketing-Abteilung von Altova benötigte daher eine praktische Methode, um Kunden und Partner ständig über diese Inhalte auf dem Laufenden zu halten und enschied sich dazu, eine Applikation zur Erstellung und Veröffentlichung regelmäßiger RSS Feeds zu entwickeln. Verwendet werden sollte die Applikation zur Bearbeitung von RSS Feeds (RSS Edition Solution = RES) vom PR-Manager des Unternehmens, der für die Veröffentlichung der Pressemitteilungen und E-Newsletter verantwortlich ist und der in der Lage sein sollte, Informationen darüber sofort und unabhängig von anderen Abteilungen online stellen zu können. Zur Erstellung einer solchen Unternehmenslösung verwendete die Marketing-Abteilung von Altova ausschließlich eigene Tools aus dem Altova MissionKit® Software-Paket. Bald wurde beschlossen, das Projekt weiter auszubauen und die Lösung als Beispiel für den Einsatz von Altova-Tools - unter Verwendung von XML-Standards und Spezifikationen - zur Lösung ähnlicher Aufgaben zur Verfügung zu stellen. In dieser Fallstudie wird daher nicht nur die Entwicklung einer nützlichen Geschäftsapplikation dokumentiert, die ausschließlich mit Hilfe und auf Basis von Altova Produkten erstellt wurde, sondern es entstand daraus eine voll funktionsfähige und einfach zu bedienende und jederzeit modifizierbare Anwendung zur Bearbeitung von RSS Feeds. Das Endprodukt, die Altova Authentic RSS Editing Solution (RES) ist eine einfache und KOSTENLOSE Applikation, die mit dem Altova MissionKit erstellt wurde und mit der jeder Laie RSS 2.0 Dokumente zur Veröffentlichung im Web erstellen und bearbeiten kann. Aufgabenstellung Das Marketing-Team wusste, dass es die nötigen Tools zur Erstellung einer Lösung zur RSS-Bearbeitung zur Veröffentlichung der eigenen RSS Feeds zur Verfügung hatte und wollte die Software-Entwickler des Unternehmens, die bereits mit der Weiterentwicklung der Altova-Produkte für die nächste Release beschäftigt waren, nicht mit dieser zusätzlichen Aufgabe belasten. Daher wurde der Produkt Marketing Manager, der bereits Erfahrung in der Arbeit mit Altova Software-Applikationen hatte (hauptsächlich zur Erstellung von Web Content und zur Präsentation von Produktfeatures bei Messeveranstaltungen), der jedoch keine Erfahrung mit der Erstellung von Applikationen hatte, mit dieser Aufgabe betraut. Mit Hilfe der einzelnen Komponenten des MissionKit musste eine formularbasierte Applikation erstellt werden, mit der ein Normalanwender gültige RSS-Dokumente zur Veröffentlichung auf der Altova-Website erstellen kann. Eine der Schwierigkeiten bei der Arbeit mit RSS-Spezifikationen ist, dass viele der Spezifikationen - obwohl Sie auf XML basieren, einer Markup-Sprache, die in einem XML-Schema ausführlich definiert und verwaltet werden kann - nur durch individuell erstellte Beschreibungen definiert werden und keinem Schema zugeordnet sind. Dadurch wird die Validierung und die Erstellung eines Stylesheet oft zu einer mühseligen Aufgabe. Nachdem das Team beschlossen hatte, die RSS-Lösung öffentlich zugänglich zu machen, musste die Lösung erweitert werden, sodass sie auch für Benutzer außerhalb des Unternehmens brauchbar war. Die Lösung musst also vielseitiger werden und es wurde ein Mechanismus benötigt, um bereits vorhandene Feeds und Daten zu importieren. Die Anforderungen Es wurden die folgenden Software-Komponenten des Altova MissionKit verwendet:
Vor Beginn der RSS-Applikationserstellung mussten die Projektanforderungen analysiert und ein Plan für die genaue Vorgehensweise erstellt werden. Dazu wurde eine Reihe von Altova UModel-Diagrammen erstellt, in denen die voraussichtlichen Interaktionen mit der fertigen Applikation dargestellt wurden.
Diese Diagramme bildeten das Grundgerüst, anhand dessen die Applikation entwickelt wurde. Lösung Auswahl einer SpezifikationRSS (steht für "Really Simple Syndication") ist eine Familie von Web Feed-Formaten, die zur Veröffentlichung häufig aktualisierter Inhalte wie z.B. Blog-Einträge, Schlagzeilen oder Podcasts verwendet werden... RSS-Formate werden mittels XML, einer allgemeinen Spezifikation zur Erstellung von Datenformaten definiert. (Wikipedia) Zur Auswahl steht eine Reihe unterschiedlicher Versionen der RSS-Spezifikation. Nach sorgfältiger Prüfung der Anforderungen und der verfügbaren Spezifikationen entschied sich das Team für RSS 2.0. Die Wahl fiel nicht nur aufgrund der Beliebtheit der Spezifikation auf RSS 2.0 sondern auch aufgrund des einfachen und verständlichen XML-Markup-Codes. Die RSS 2.0 Spezifikation besteht aus einer Gruppe relativ genau definierter und vielfältiger Elemente, die eine klare Elementhierarchie und klare Datenformate vorgeben. Die Dokumentation dazu finden Sie unter: http://cyber.law.harvard.edu/rss/rss.html Die BeispieldateiAufgrund der Tatsache, dass es sich bei der RSS-Spezifikation um ein XML-Vokabular handelt, hatte Altova als Entwickler von Tools für alle XML-Technologien, die idealen Voraussetzungen zur Entwicklung einer RSS-Editierlösung. Zuvor hatte das Team die RSS-Feeds manuell mit Hilfe von XMLSpy, dem XML Editor von Altova, codiert, wobei es Elemente aus dem RSS 2.0 Elementset verwendet hatte. Anhand eines repräsentativen Beispiels für diese Feeds als Basis für das neue Projekt konnte das Team sein Anforderungsprofil an die durch das Vokabular des Formats vorgegebenen Richtlinien anpassen. Auf diese Art konnten die Formulare erstellt werden, die schließlich dem RES-Benutzer zur Verfügung stehen sollten. Anfangs schien die Aufgabe einigermaßen unkompliziert. Mit Hilfe von Altova StyleVision konnte ein Stylesheet zur Erstellung eines Authentic-Eingabeformulars erstellt werden. Über dieses Formular konnten auch Normalanwender den Inhalt eines RSS-Feed einfach in Form von Text eingeben, ohne sich um den zugrunde liegenden XML-Code kümmern zu müssen. Doch bald stieß das Team auf die erste Hürde: Zur Erstellung des Stylesheet wurde ein XML-Schema benötigt. RSS 2.0 ist allerdings eine XML-Spezifikation, für die es weder ein XML-Schema, noch eine DTD oder auch nur einen vordefinierten XML Namespace zur Validierung oder Regelung des XML-Inhalts gibt. Die SchemasZum Lesen der RSS-Feeds stehen Hunderte von RSS Reader zur Verfügung. Wie ein RSS-Feed dem Endbenutzer angezeigt wird, hängt direkt vom gewählten Reader ab, den dieser gewählt hat. So ignorieren manche Feed Reader möglicherweise Inhalt, der laut Spezifikation ungültig ist, in anderen wiederum wird der Inhalt dennoch angezeigt. Aufgrund dieser Tatsache beschloss das Team, zur Erstellung gültiger RSS 2.0 Feeds ein XML-Schema (.xsd) zu verwenden. Die W3C XML Schema Definition Language (XSD) ist ein effizientes Mittel, um die Struktur von XML-Dokumenten zu definieren. Anhand dieser Sprache kann der Benutzer bei der Bearbeitung von XML auf Basis des definierten Content Model gültige Dokumente erstellen. Da RSS 2.0 kein offizielles Schema hat, mit dem der Standard verknüpft ist, sondern nur eine Reihe von Regeln, die im definierten Dokument beschrieben sind, gibt es keine vordefinierte Methode, mit der Sie sicherstellen können, dass die RSS-Instanzen gültig sind. Der Inhalt des Feed muss sorgfältig und in mühsamer Arbeit mit der Spezifikation verglichen werden. Daher wurde mit Hilfe von XMLSpy ein Schema anhand des RSS-Feed-Beispiels erzeugt. Das erzeugte XML-Schema war einigermaßen simpel, da es ausschließlich auf den im Beispieldokument definierten Elementen basierte - nämlich denjenigen, die das Team für die geeignetsten für die Altova-Zwecke hielt.
Anschließend wurde das generierte Schema überprüft und es wurden die notwendigen Anpassungen daran vorgenommen. Bald stellte sich jedoch heraus, dass ein robusteres Schema benötigt wurde, wenn das RES-System auch Benutzern außerhalb von Altova zur Verfügung gestellt werden sollte. Während der Analyse des Schemas stellte sich ein weiteres Problem heraus: Der für das RSS 2.0 Element <pubDate> verwendete Datentyp war ein String und basierte auf der uralten (1982) Datums- und Uhrzeitspezifikation RFC 822, was bedeutete, dass der Benutzer das Datum manuell ins Formular eingeben musste, eine sehr fehleranfällige und schwer zu validierende Methode. Da in diesem Element außerdem englische Monatsnamen und eine englische Sequenzierung erforderlich waren, eignete es sich nicht für die internationale Verwendung durch Web-Editoren und Endbenutzer. Feeds mit ungültigem Inhalt würden von einigen RSS Readern womöglich nicht akzeptiert werden. Daher beschloss man, auch diese Probleme im Schema zu beheben. Bei einer schnellen Suche im Web wurde ein öffentlich verfügbares RSS 2.0 XML-Schema gefunden (http://www.thearchitect.co.uk/schemas/rss-2_0.xsd) das einen Validierungsmechanismus für das Element <pubDate> sowie Schemadefinitionen für viele in der umfangreichen RSS 2.0 Spezifikation definierte optionale Elemente enthielt. Doch auch damit ergab sich keine befriedigende Lösung, da damit nur die Form des Datenstring nicht aber sein Inhalt validiert werden konnte. Laut Schema war z.B. <pubDate>32 Aug 2007 09:00:00 EDT</pubDate> ein korrekt geformter String. Leider wurde nicht erkannt, dass August ein Monat mit nur 31 Tagen ist. Der Produktmarketing-Manager führte die beiden Schemas zusammen, um ein XML-Schema zu erzeugen, in dem die für die Verwendung in den Altova-Feeds benötigten XML-Elemente sowie viele für externe Endbenutzer erforderliche Elemente beschrieben wurden. Die Datei erhielt den Namen Publish.xsd. Anhand des neuen Schemas und des Altova RSS Feed als Beispiel für eine Eingabedatei, begann der Produktmarketing-Manager nun mit Hilfe von StyleVision das Stylesheet für das Authentic-Formular zu erstellen, doch das unpraktische RFC 822-Datumsformat stellte weiterhin ein Problem dar. Nach Analyse des Projekts entschied sich das Team dann für eine neue Strategie:
Zu diesem Zeitpunkt mussten die neuen Projektanforderungen und der Lösungsansatz dokumentiert werden, um einen Plan zu entwickeln. Zu diesem Zweck wurden die UML-Projektdiagramme in UModel überarbeitet und um zusätzliche Zustandsdiagramme und ein Deployment-Diagramm ergänzt. Diese Diagramme sowie weitere Projektdiagramme sind im RES . Zip-Archiv in der Datei UMLprojectdocs.rtf gespeichert.
Bitte beachten Sie: Es gibt viele andere mögliche Lösungsansätze für das oben erwähnte <pubDate> Problem. Aber da man ja eine möglichst einfache und verständliche Lösung entwickeln wollte, entschied man sich bei Altova, nicht mit XML Namespaces oder anderen derartigen Technologien zu arbeiten. Die StylesheetsDa es sich bei der Zielgruppe der RES-Benutzer ja um Normalanwender handelte, mussten einfache und intuitive elektronische Formulare zur Erstellung gültiger RSS-Dokumente entwickelt werden. In einem Stylesheet ist die Darstellungsstruktur vom semantischen Inhalt getrennt. Dank dieser Methode der Informationsspeicherung, bei der das Layout als separates Dokument definiert wird, können Entwickler Design-Vorlagen erstellen, die von einem anderen Benutzer wiederverwendet werden können. Das Team erstellte mit Hilfe der grafischen Design-Oberfläche und der Drag-and-Drop-Funktionalitäten von Altova StyleVision zwei Stylesheets, eines für ein Authentic-Formular mit editierbaren Feldern, das zur Eingabe der Daten dienen sollte (Author.sps), und eines, mit Hilfe dessen die Daten der RSS 2.0-Spezifikation entsprechend umformatiert und vor der Veröffentlichung zur Überprüfung angezeigt werden sollten (Publish.sps).. Außerdem wurden mit Hilfe von StyleVision nützliche Tipps oder "Benutzerinformationen" zu editierbaren Elementfeldern der Datei Author.sps hinzugefügt, um Content Editoren bei der Eingabe gültiger RSS 2.0 Daten zu helfen. Zur Behebung des oben erwähnten <pubDate>-Problems wurde ein Datums-/Uhrzeit-Tool in das Eingabe-Stylesheet integriert, sodass eine Datumswahl sowie Enumerationen zur Auswahl von Uhrzeit und Zeitzone zur Verfügung standen.
Der Benutzer musste nun bei der Erstellung eines RSS Feed bei der Eingabe von Datum, Uhrzeit und Zeitzone nicht mehr manuell einen komplizierten Zeichenstring eingeben. Das Datum konnte aus einem Kalender und Uhrzeit und Zeitzone aus Dropdown-Listen ausgewählt werden. Bevor das Datums-Tools zum Stylesheet hinzugefügt werden konnte, musste das Schema natürlich um die zusätzlichen Elemente erweitert werden. Mit dem grafischen Schema Editor in XMLSpy wurde das zuvor erstellte Dokument Publish.xsd bearbeitet und <pubDate> wurde durch die neuen Elemente <inDate>, <releaseTime> und <timeZone> ersetzt. Diese neue Schema-Instanz wurde anschließend als Author.xsd gespeichert.
Die Benutzer des RES arbeiteten nur mit den Authentic-Formularen, sodass jeder Normalanwender nun RSS-Inhalt in Echtzeit bearbeiten und veröffentlichen konnte, ohne die zugrunde liegende Technologie verstehen zu müssen. Bitte beachten Sie: Sie können in StyleVision an allen Teilen der oben genannten .sps-Datei Änderungen vornehmen. Sie können z.B. auch das Format des Datums/Uhrzeit-Tools ändern. Die MappingsNachdem nun der Grundstein für diesen zweiteiligen Lösungsansatz gelegt war, mappte das Team das Schema "Author" nun mit Hilfe von MapForce auf das Schema "Publish". Um den Inhalt der Elemente <inDate>, <releaseTime> und <timeZone> zu kombinieren und korrekt als RFC 822 String zu formatieren, wurde eine benutzerdefinierte MapForce-Funkion erstellt. Der Endbenutzer konnte nun RSS-Daten in ein Formular eingeben, das das Tool zur Datumswahl enthielt. In der RES-Ausgabe wären diese Datumsangaben jedoch gemäßt dem RSS 2.0 Standard im Format <pubDate> enthalten.
Da viele externe Benutzer des RES wahrscheinlich frühere Feeds in das Tool importieren werden möchten, um sie bearbeiten zu können, hat das Team ein weiteres Mapping von Publish.xsd auf Author.xsd erstellt, damit gültige RSS 2.0-Dokumente auch unter Verwendung des Elements <inDate> bearbeitet werden können. Ergebnis dieser Mappings waren zwei XSLT-Dateien, eine zum Transformieren des <pubDate>-Elements in das Format des Datums- / Uhrzeittools und eine zum Transformieren des Datums- / Uhrzeittools in ein gültiges <pubDate> Element, das der RSS 2.0-Spezifikation entspricht. Das Authentic-ProjektAuszug aus dem Mapping für die benutzerdefinierte Funktion für das Datums- / Uhrzeit-Tool Nach Generierung bzw. Erstellung der Schemas, Stylesheets und Mappings musste nun nur noch ein Authentic-Projekt entwickelt werden, über das ein Benutzer die Lösung verwenden und den Inhalt der Feeds verwalten konnte.
Das Projekt besteht aus vier verschiedenen Verzeichnissen, die die folgenden wichtigen Dateien enthalten:
Die folgenden drei zusätzlichen Verzeichnisse sind im Ordner Authentic_RSS_Solution.zip enthalten:
RSS-Dateien haben oft unterschiedliche Erweiterungen (z.B: xml, rss, und im Fall der Dateien in unserem Ordner "Author" .rssa). Im Authentic-Projekteigenschaftenfenster wurden alle Verzeichnis- und Dateiverknüpfungen definiert, um sicherzustellen, dass Authentic relevante Dateiformate akzeptiert, Dateien im richtigen Verzeichnis gespeichert werden und die richtigen Schema- und XSLT-Instanzen sowie .sps-Dateien verwendet werden. Mit der Lösung erstellte Feeds werden mit der Erweiterung .xml gespeichert und standardmäßig im Ordner "Publish" abgelegt, doch sowohl die Dateierweiterung als auch der Zielordner können vom Benutzer im Fenster "Eigenschaften" konfiguriert werden.
Ergebnis Altova verfügt nun über eine einfache und intuitive Lösung zur Bearbeitung von RSS Feeds, die den Anforderungen der Marketing-Abteilung entspricht und auch Altova-Kunden kostenlos zur Verfügung steht. Diese Applikation ist ein Beispiel für die Lösung einer realen Aufgabe mit Altova-Tools. Der PR-Manager kann den Inhalt des RSS Feed in Echtzeit aktualisieren, ohne sich mit dem XML-Code befassen zu müssen.
Anpassbarkeit Auf Wunsch können Sie dieses Projekt weiterbearbeiten und an Ihre eigenen individuellen RSS-Anforderungen adaptieren. Laden Sie dazu den Altova MissionKit herunter. Der MissionKit enthält alle Tools die Sie benötigen, um:
Auf Wunsch können Sie sogar die Eigenschaften des Projektordners ändern oder eine vollkommen neue Projektdatei erstellen. (TIPP: Dieselbe Projektdatei lässt sich sowohl in XMLSpy als auch Authentic verwenden. In der Authentic-Ansicht von XMLSpy sieht der Entwickler eine Vorschau der Endbenutzeroberfläche.) Sie können auch kleine Änderungen vornehmen, z.B. unsere Definition der Veröffentlichungszeit erweitern, damit auch jede Minute einer Stunde akzeptiert wird. Außerdem könnten Sie optionale Elemente aus der RSS 2.0 Spezifikation hinzufügen, die unser Team nicht in das Projekt inkludieren wollte. Sie könnten sogar einige von uns inkludierte Elemente entfernen. Alle Dateien, die Sie benötigen, sind in der Datei Altova RSS Editing Solution .zip enthalten und können jederzeit von Ihnen bearbeitet werden. Zusammenfassung Zwar konzentiert sich diese Fallstudie auf spezielle Probleme beim Erstellen der Altova Authentic-Lösung zur Bearbeitung von RSS-Feeds, doch enthält dieses Projekt auch Beispiele für häufige Problemstellungen bei der Arbeit mit Standards/Spezifikationen in XML-Projekten. Die Gewährleistung der Standardkonformität ist - selbst bei relativ kleinen Projekten wie diesem - immer eine heikle und zeitraubende Aufgabe. Für Projekte wie dieses sind die richtigen Tools und Ressourcen unentbehrlich. Auch eine sorgfältige Planung gewährleistet den reibungslosen Ablauf des Entwicklungsprozesses. Was kommt als nächstes?
| |
| | ||||||||||||||||||||||||||||||||||||||||||||||
| Altova | Rechtsabteilung | Presse | Partner | Karriere | Übersicht | Kontakt | Altova Blog | Mobile | Full Site | |||
|
