Content Syndication Requirements Specification Author

Content Syndication - 5/24/2004

Revision Number

Date

TopCoder Software, Inc. 2004

Page 1 of 7

Application Requirements Specification

3

1.

Scope 1.1 Overview 1.2 Objectives 1.3 Limitations

3 3 3 3

2.

Logic Requirements 2.1 Setting up contacts 2.2 Selecting Content For Syndication 2.3 Retrieving Content 2.4 Content Format 2.5 Application server Integration 2.6 Integrating ROMAN

3 3 4 4 4 5 5

3.

Technical Requirements 3.1 Graphical User Interface Requirements 3.2 Communication Interfaces 3.3 Environment Requirements 3.4 Are there particular frameworks or standards that are required? 3.5 TopCoder Software Component Dependencies 3.6 Third Party Component, Library, or Product Dependencies 3.7 Design Constraints 3.8 Performance Constraints

5 5 5 5 6 6 6 6 6

4.

Required Documentation 4.1 Specification Documentation

6 6

5.

Help / User Documentation

6

6.

Notes

6

7.

Future Enhancements

7

Content Syndication - 5/24/2004

TopCoder Software, Inc. 2004

Page 2 of 7

Application Requirements Specification 1. Scope 1.1 Overview Today content syndication is an extremely manual and intensive process for employees. The goal of this system will be to automate as much of the content syndication project as possible. Automating this project will remove the majority of the manual intervention needed to distribute content. Users will select content for syndication through an interactive front end for “ordering” content. The selected content will then be converted to the customer specific XML format and transported using the a Content Syndication server. Additionally, reporting and historical tracking will be built into the system. Users will be able to track who has been sent what content and when the content was sent. From an architecture standpoint, the new system will be developed in Java instead of Microsoft technologies. Although, some integration points with the existing system will be developed in Microsoft VB/ASP technologies. By building the system externally from the internal system, all dependencies on the current system will be removed, facilitating a potential upgrade to a new digital rights management system. 1.2 Objectives The new content syndication project will create an easy to use integrated and automated content syndication system. • Remove manual steps in producing content for syndication. • Deliver the ability to select multiple articles for syndication. • Provide a mechanism to create configurable XML for delivery to syndication partners. • Feed the application server customized XML for each syndication partner. • Remove sent files from application server queue. • Link the internal databases once syndication occurs. 1.3 Limitations • •

There will be no administration facility for XSLT style sheets. Creating and editing XSLT style sheets is outside the scope of this project. Currently, report generation for content syndication is external to the scope of this product.

2. Logic Requirements 2.1 Setting up contacts 2.1.1 Assigning Style Sheets The database maintains a list of contacts. An enhancement to the existing database will be made to store an XSLT style sheet for each contact. A user will first search for specific the contact. From the search results page, the user will select the contact to edit. The administration tool will provide a BROWSE button, allowing the user to browse to the XSLT style sheet to load to the application server. 2.1.2 Creation and Editing of XSLT Style Sheets TopCoder will create style sheets for all existing contacts. A style sheet will be created for each of the current 6 distinct vendor formats and for a standard content. An IT staff member will be responsible for creating new or modifying existing style sheets. There will not be a user interface for this task. The style sheet will be modified externally from the system and re-assigned to the contact through the admin tool. 2.1.3 Storage of Style Sheets During the design phase, the designer will decide where the appropriate place is to store the Content Syndication - 5/24/2004

TopCoder Software, Inc. 2004

Page 3 of 7

style sheets. The options include storing the style sheet on the file system or in the database. 2.1.4 Mapping the Offer to the Contact The database will contain a field to map the database contact to an offer in the application server. The offer id from application server will be mapped to a database contact. 2.2 Selecting Content For Syndication 2.2.1 Searching for content A user will utilize the search capabilities of the application. After entering the search criteria, the user will select the syndicate content button. 2.2.2 Selecting content Once the syndication button has been pressed by the user, the search results will be displayed with select boxes for each piece of content. The user will then select all of the content to syndicate, the contact to syndicate the data to and press the “Syndicate” button. Assuming, the selection passes validation, the data will be stored to the database. 2.2.3 Selection Validation The user will be required to select one and only contact and at least one story. If the same story is pending for the same contact, an additional record will not be created for that specific content for the contact. Furthermore, if the same content was already sent to the contact an error will be displayed stating the same content can not be resent. 2.2.4 Access Rights All content selected for syndication must have the correct syndication permissions. The access rights must be marked “All” and cannot be marked “See Contract” or any other permission. Any access rights that are not marked “All” will be “grayed out” and will not be selectable. In order to mark the content rights to “All”, a user must contact an administrator to mark the content with rights of “All” after reviewing the content’s contract. The administrator will then adjust the permissions to allow the user to download the content and afterwards the administrator will return the permissions back to the correct level. 2.2.5 Storing content selection After the content has been selected for syndication the data will be persisted to a database table. The data will be time stamped and assigned to the appropriate contact at creation time. A status will also be set on the data to flag it ready for syndication. The XML retrieval process will be responsible for retrieving and creating the XML for syndication. An additional syndication timestamp will be updated when the content has been syndicated. 2.3 Retrieving Content 2.3.1 Scheduled Intervals At regularly scheduled intervals, a process will retrieve the content for syndication from the database. All content for a single contact will be created in one file. 2.3.2 Retrieving Content The process will retrieve all of the pending content for a specific content. Once all the pending content has been selected it will be formatted specifically for the contact. 2.4 Content Format 2.4.1 XML Formatted Content All content to be syndicated will be exported as an XML document. Each recipient will Content Syndication - 5/24/2004

TopCoder Software, Inc. 2004

Page 4 of 7

receive one XML file containing all of the exported content. One standard XML data output will be created for the entire system. The outputted data will be mapped to a SQL statement. If the SQL statement changes, the outputted data will change to match the result set. In the event that the SQL statement needs to be altered, an IT resource will be needed to update the SQL statement. However, it will not require a code change, just a configuration adjustment. 2.4.2 Contact Specific XML Formats Each client will be assigned one XSLT style sheet. The XSLT style sheet will be responsible for formatting the standard XML into the contact specific XML format. Once the XML has been translated to the contact specific XML, the XML message will be transferred to the application server system. 2.5 Application server Integration 2.5.1 Content Delivered by Offer The application server allows users to set up “offers”. An “offer” is the distribution of content to another party, in this case a contact. Content will be syndicated to specific offers which map directly to a contact. 2.5.2 Implementation TopCoder will investigate utilizing the application server Java API. The design phase will determine if this is the best approach. If it is not, TopCoder will follow architecture of the current implementation which utilizes the file system monitoring component. The best solution for reliability and error tracking appears to be the API. 2.6 Integrating ROMAN 2.6.1 Updating Usage Information Once the content has been successfully transmitted to the application server Server, the database needs to be updated with usage information. After extracting the Access Key from the XML database, usage table in the ROMAN database will be updated.

3. Technical Requirements 3.1 Graphical User Interface Requirements The user interface will be provided through the existing system, web-based front-end that will minimize requirements for installation and configuration. Since the client has decided their websites will be designed for browsers versions 5.0 and later, client side JavaScript will be used for cookie processing. A detailed specification of the User Interface will be defined during System Design activities, however the following are general properties that will be included: • All pages will be returned in 3 seconds or less. 3.2 Communication Interfaces The communications interface will require an internet connection. 3.3 Environment Requirements 3.3.1 Operating System •

Windows Server 2000

3.3.2 Software Development Versions • • •

SQL Server 2000 JDK 1.4 COM+

Content Syndication - 5/24/2004

TopCoder Software, Inc. 2004

Page 5 of 7

•

ASP

3.3.3 Data Stores SQL Server 2000 is the production database. 3.3.4 Application Server An application server will host the java programs. 3.3.5 Web Server The web server will be Internet Information Server (IIS) version 6.0. 3.4 Are there particular frameworks or standards that are required? • •

Java JDK 1.4 ASP/COM

3.5 TopCoder Software Component Dependencies • • • • • • • •

Job Scheduler Document Generator File System Search File Class Base Exception Logging Wrapper Configuration Manager QueryResult2XML

3.6 Third Party Component, Library, or Product Dependencies • • • •

Java Version 1.4 XML, XSD standards HTTP / HTTPS 1.0 SQL Server 2000

3.7 Design Constraints •

All web content will be deployed on IIS. In the future the web servers may scale horizontally. All code will take advantage of the clustering capabilities.

3.8 Performance Constraints The current web site performance will not degrade with the addition of the new functionality.

4. Required Documentation 4.1 Specification Documentation • • • • • •

High Level Use Case Diagrams Deployment Diagram Architecture Diagram Activity Diagram Diagrams Requirements Specification HTML Website Prototype

5. Help / User Documentation No additional user documentation required. The system will be designed to incorporate user help in a future release.

6. Notes None.

Content Syndication - 5/24/2004

TopCoder Software, Inc. 2004

Page 6 of 7

7. Future Enhancements None.

Content Syndication - 5/24/2004

TopCoder Software, Inc. 2004

Page 7 of 7