RSS Editing Solution Case Study

RSS Editing Solution Case Study

Altova, the XML market leader and creator of XMLSpy®, needed a simple and effective way to create RSS feeds for its marketing staff to publish information about new content on the corporate Web site.

Overview

As a progressive and cutting-edge software provider, Altova has a Web site which is constantly evolving with the addition of new product feature descriptions, press releases, newsletters, solution briefs, and other content. Altova’s marketing team needed a convenient way to keep their customers and partners apprised of this content in real-time, and decided to develop an application for creating and publishing regular RSS feeds.

The target user for the RSS editing solution was the company’s Public Relations Manager, who publishes Altova’s press releases and e-newsletter and needed to be able to post information about them immediately and independently, without having to request code from other departments.

Exclusively using tools available in the Altova MissionKit® software suite, the marketing team at Altova was able to create a corporate RSS editing solution. They soon decided to expand the project and make it a freely available solution that would demonstrate how Altova tools could be used to solve similar business issues — working with industry-specific XML standards and specifications. Thus, this case study not only documents the development of a useful business application built from and based exclusively on Altova products, but it also produced a fully functional and straightforward RSS editing solution that anyone can use (and modify at will).

The resulting Altova Authentic RSS Editing Solution (RES) is a lightweight and FREE application created with the Altova MissionKit, which gives non-technical users the ability to create and edit RSS 2.0 documents for publication on the Web.

The Challenge

The product marketing team knew that they had the tools at their disposal to create an RSS editing solution in order to publish its own feeds and did not want to assign the task to the software development team who were always busy preparing upcoming product enhancements and releases. Therefore, the challenge was assigned to a product marketing manager, who was experienced using Altova software applications (mostly for creating Web content and demonstrating product features at industry trade shows), but had no previous application engineering expertise.

Using individual components from the MissionKit, the product marketing manager needed to create a form-based application for non-technical users to produce valid RSS documents for publication to the Altova corporate Web site. One of the difficult aspects of working with the RSS specifications is that even though they are based on XML, a markup language which can be extensively defined and managed by a XML Schema, many of the specifications are defined only by human descriptions and have no Schema associated with them. This makes validation efforts and stylesheet design arduous tasks.

Once the team decided to make the RSS solution public, the solution needed to be extended so that it would be useful to users outside of the company. This meant that it had to be more versatile and there needed to be a mechanism in place for importing feeds and data that already existed.

The Requirements

The Altova MissionKit software components used for this solution were:

Before beginning to build the actual RSS editing application, the product marketing manager and his team needed to review the project requirements and develop a concise plan for how to proceed. In doing this, they created several diagrams using Altova UModel, which outlined anticipated user interaction with the finished application.

UModel diagram

UModel diagram - Edit existing RSS feed

These diagrams provided the wireframes from which the team would proceed with the development process.

The Solution

Choosing a Specification

RSS (which, in its latest format, stands for "Really Simple Syndication") is a family of web feed formats used to publish frequently updated content such as blog entries, news headlines, or podcasts... RSS formats are specified using XML, a generic specification for the creation of data formats. (Wikipedia)

There are several different versions of the RSS specification to choose from. After a careful review of Altova’s requirements, as well as the specifications available, the team chose to work with RSS 2.0. RSS 2.0 was considered to be an ideal choice primarily because of the specification’s popularity, but also because it uses straightforward human-readable XML.

The RSS 2.0 specification is comprised of a fairly strict and extensive element set, which does a fair job of dictating the element hierarchy and required data formats. This documentation can be found online at: http://cyber.law.harvard.edu/rss/rss.html

The Example File

The fact that the RSS specification is actually an XML vocabulary meant that Altova, as a developer of tools that support all XML technologies, was uniquely situated to develop an RSS editing solution.

The team had previously used Altova’s XML editor, XMLSpy, to hand code RSS feeds using elements provided by the RSS 2.0 element set. Using a representative sample of these feeds as a basis for the new project allowed them to reconcile the requirements they had already anticipated with the guidelines dictated by the format’s vocabulary. In doing so, they were able to begin visualizing the forms that would eventually be presented to RES users.

At first, the project appeared to be fairly straightforward. Using Altova StyleVision, a stylesheet could be created to design an Authentic input form. This form would allow non-technical users to enter RSS feed content in plain English, without having to worry about writing the underlying XML code.

Soon, the team encountered their first hurdle: creation of the stylesheet would require an XML Schema. But RSS 2.0 is an XML specification defined without an XML Schema, a DTD, or even a pre-defined XML namespace to assist with validation or enforcement of XML content.

The Schemas

There are hundreds of RSS readers available to choose from, and the way that RSS feeds are displayed to end users is directly determined by the reader that they have chosen to use. For example, some feed readers may ignore any content that is not valid according to the specification, while some will display it regardless. Because of this, the team determined that an XML Schema (.xsd) should be used to enforce creation of valid RSS 2.0 feeds.

The W3C XML Schema Definition Language (XSD) is a powerful mechanism for defining the structure of XML documents. When used as a reference, it can help XML editors create valid documents based on the specified content model. Because RSS 2.0 does not have an official schema associated with it, only a set of rules which are described in the specification document, there is no pre-ordained way in which to ensure that RSS instances are valid without a careful and exhaustive comparison of the content of the feed file with the specification.

To address this issue, XMLSpy was used to generate a schema from the sample RSS feed. The resulting XML Schema was fairly basic because it was based exclusively on the elements defined within the sample document — those that Altova had decided were most appropriate for their internal use.

Generating a schema from an XML instance

Generating a schema from an XML instance

The team then reviewed the generated schema and began to make a few required tweaks to suit their content. However, it soon became obvious that if the RES was to be offered to users outside of Altova, a more robust schema needed to be developed.

In the course of their analysis, the team came across another challenge: The datatype used for the RSS 2.0 <pubDate> element was a string, based on the archaic (1982) Date and Time Specification RFC 822, meaning that user input would have to be entered freeform and was thus error prone and difficult to validate. Also, because this element required English month names and sequencing, it was inefficient for international Web editors and end users. Feeds with any invalid content could be rejected by RSS readers. Therefore, it was decided that the schema should be designed to address these issues as well.

A quick Web search revealed a publicly available RSS 2.0 XML Schema (http://www.thearchitect.co.uk/schemas/rss-2_0.xsd) that included a validation mechanism for the <pubDate> element and offered schema definitions for many optional elements defined in the extensive RSS 2.0 specification. However, even this admirable effort was only able to validate the form of the date string, not the content that it contained. For instance, the schema could report that <pubDate>32 Aug 2007 09:00:00 EDT</pubDate> was a correctly formed string, but could not detect that August is a month with only 31 days.

The product marketing manager merged the two schemas to create an XML Schema to describe the XML elements intended for use in the Altova feeds, as well many elements required for external end users. This file was named Publish.xsd. Using the new Schema and the Altova RSS feed as an example input file, the product marketing manager began designing the stylesheet for the Authentic form using StyleVision, but the cumbersome RFC 822 date format continued to present a problem.

The product marketing manager reviewed the project with the team and a new strategy emerged:

1. Create a small but efficient XML Schema and stylesheet for an entry form optimized for end-user input.

2. Employ an XSL transformation to create standard RSS 2.0 output from files based on the optimized input schema. This would enable users to input date and time information with an easy-to-use date/time widget that would be translated into the convoluted RFC 822 date format.

3. Create the necessary XSLT code for the transformation by visually mapping between the end-user input schema and the RSS 2.0 output schema using Altova MapForce and then using MapForce’s built-in code generator to generate XSLT 2.0 code.

4. Tie together the input stylesheet, XSL files, and output files in an Authentic Project to efficiently manage the RSS creation process.

At this point, the product marketing manager and his team needed to document the new project requirements and the solution strategy to develop an organized plan. To do this, they revised the project UML diagrams in UModel and added additional state machine diagrams and a deployment diagram to capture the solution logic. This and other project diagrams are included in the RES .zip archive in the UMLprojectdocs.rtf file.

UModel diagram

UModel diagram: Life of a New RSS Feed

It is important to note that there are many other possible workarounds for the <pubDate> issue mentioned above. But in keeping with their original plan of building the most straightforward and human-readable solution possible, the Altova product marketing team chose to forego the use of XML Namespaces or any other such technology.

The Stylesheets

Because the target RES users were to be non-technical, the product marketing team needed to develop simple and intuitive electronic forms that would guide the development of valid RSS documents.

Stylesheets separate presentation structure from semantic content. This method of storing the information that defines layout as a separate document enables developers to create design templates that editors can reuse as needed.

The team used Altova StyleVision’s graphical design interface and drag-and-drop functionality to create two stylesheets, one for an Authentic form with editable fields that would be used for entering data (Author.sps), and one that would be used to reformat that data according to the RSS 2.0 specification and display it for review prior to publishing (Publish.sps). Using StyleVision, the team was also able to add useful tips or “user info” to the editable element fields of the Author.sps file, which would help content creators to input valid RSS 2.0 data.

To solve the <pubDate> issue mentioned above, a date/time widget was incorporated into the input stylesheet, providing a date picker, as well as enumerations for time and time zone.

Date/time widget in Authentic view

Date/time widget in Authentic view

Now the user creating an RSS feed would no longer have to type a complicated string of characters by hand to represent the date, time, and time zone. The date would be selected from a calendar, and the time and time zone picked from enumerated pull-down lists.

Of course before the date widget could be added to the stylesheet, the schema had to be edited to incorporate the additional elements. Using the graphical schema editor in XMLSpy, the product marketing manager edited the Publish.xsd document that they had already produced to replace <pubDate> with the new elements <inDate>, <releaseTime>, and <timeZone>. This new schema instance was then saved as Author.xsd.

Author.sps

Altova StyleVision Power Stylesheet (Author.sps) for the input Authentic form displayed in StyleVision with user information visible when the cursor is placed over an editable node



Publish.sps

Altova StyleVision Power Stylesheet (Publish.sps) for review of RSS 2.0 content prior to publishing

The Authentic forms were to be the only point of contact for users of the RES, meaning that the non-technical user would now be able to edit and post RSS content in real time, without being exposed to any of the underlying technology.

StyleVision users have the ability to make changes to all aspects of the .sps files above, including for example, changing the format of the date/time widget.

The Mappings

After laying the groundwork for this two-step approach, the team used Altova MapForce to map the Author schema to the Publish schema. A MapForce user-defined function was built to combine the contents of the <inDate>, <releaseTime>, and <timeZone> elements and format them correctly as an RFC 822 string. Now the end user would be able to input RSS data in a form which included the date widget, but the RES output would incorporate them as <pubDate> to conform to the RSS 2.0 standard.

MapForce mapping

MapForce mapping of Author .xsd to Publish.xsd



MapForce mapping detail

Detail of the mapping for the date/time widget user-defined function

Recognizing that many external users of the RES may want to import previous feeds for editing with the tool, the team also created another mapping from Publish.xsd to Author.xsd so that valid RSS 2.0 documents would be editable using the <inDate> element as well.

These mappings produced two XSLT files, one would take the <pubDate> element and transform it for compatibility with the date/time widget, and the other would take the date/time widget and translate it to a valid <pubDate> according to the RSS 2.0 specification.

The Authentic Project

Detail of the mapping for the date/time widget user-defined functionNow that the team had generated and/or created the schemas, stylesheets, and mappings, all that remained was for the team to develop an Authentic Project, which would provide a simple and comprehensive way for users to utilize the solution and manage their feed content.

Authentic project window

Authentic project window

The Project is comprised of four different directories containing the following important files:

The following three additional directories are included in the Authentic_RSS_Solution.zip folder:

RSS files often have different extensions (e.g. .xml, .rss, and in the case of files in our Author folder .rssa). The Authentic Project Properties window was used to define all directory and file associations, ensuring Authentic would accept relevant file formats, that files were saved to the correct directories, and that the appropriate Schema and XSLT instances, as well as .sps files were deployed. Feeds created using the solution are saved with the .xml extension and stored in the Publish folder by default, but both the file extension and the destination folder are user configurable in the Properties window.

Authentic Project Properties window

Authentic Project Properties window

The Results

Altova now has a simple yet intuitive RSS Editing Solution which conforms to its marketing requirements as well as a freely available application to offer its customers, which demonstrates how Altova tools can solve real business challenges. The Public Relations Manager is able to maintain the RSS feed with real time content without having to do any coding.

editing the template

Editing the Altova Authentic RSS Editing Solution template

Customization

If so desired, you can take this project a step further and customize it for your own individual RSS preferences by downloading the Altova MissionKit. The MissionKit provides all the tools you need to:

If you wish, you can even change the project folder properties or create an entirely new project file. (HINT: The same project file works with both XMLSpy and Authentic. The Authentic view in XMLSpy lets developers preview the end user’s interface.)

You might want to make small changes such as expanding our definition of the publication time to accept any minute of the hour. You could add optional elements from the RSS 2.0 specification that our team decided to eliminate. Or, you could even remove some optional elements that we included.

All the files you need are contained in the Altova RSS Editing Solution .zip file and you are free to modify them as you wish.

Conclusions

Though this case study focuses on specific issues involved with creating the Altova Authentic RSS Editing Solution, the project exemplifies common issues that developers encounter when working with industry standards/specifications in XML projects. Standards conformance is a very tricky and time consuming process, even for a relatively small project like this one. For projects like this, it is vital to have the proper tools and resources at hand, which, together with careful planning, can make the development process flow much more smoothly from start to finish.

What's Next?