Cheap Java Services With Tomcat, Jsp, Php, Mysql, J2Ee, Servlet, Struts & Hibernate Hosting Support and Coldfusion Web Hosting

The child elements of the feed element are the head element, of which there can be only one, and one or more entry elements. The first child element of the feed element must be a head element. The head Element The head element is a container for metadata about the feed. The metadata is contained in several child elements of head, as follows: . The title element contains a human readable title for the information feed. The title element has no attributes. . The link element indicates a link to the source of the feed. At the time of writing the link element is not fully specified. It seems likely that the link element will have rel, type, and href attributes but the current draft does not make that clear. If a link is to an HTML or XHTMLWeb page then that page should implement the Atom Feed Autodiscovery mechanism, described later in this chapter. . The introspection and post elements are service constructs. They are used in connection with the Atom Publishing Protocol described later in this chapter. . The author and contributor elements are also child elements of the head element. . The tagline element contains a human-readable description or tagline for the feed. The id element contains a unique identifier for the feed. . The generator element indicates the software used to generate the feed. The generator element may, optionally, have a uri and a version attribute. . The copyright element contains a human-readable statement of copyright for the feed. The info element contains a human-readable statement about the feed format. The updated element contains a date/time value that indicates the most recent time that the feed was updated. The entry Element The entry document can appear as a child element of the feed element (which is described in this section) or can be the document element of an Atom Entry document (which is described later in this chapter). The entry element has the following child elements: . The title element is required. It contains a human-readable title for the entry. . The link element conveys a URI associated with the entry. At least one link element with a rel attribute with the value of alternate must be present on each entry. . The edit element is used in association with the Atom Publishing Protocol. It represents a URI that can be used to retrieve the entry for editing. The namespace URI used in the October 2004 draft of Atom 1.0 is likely to be replaced later in the specification s development. 133 Looking Forward to Atom 1.0

The Atom 1.0 feed format document is, at the time of writing, located at http://atompub.org/2004/ 10/20/draft-ietf-atompub-format-03.html. The Atom feed format mailing list is described at www.imc.org/atom-syntax/index.html. The Atom wiki is located at www.intertwingly.net/wiki/pie/FrontPage. Atom 1.0 Document Structure Atom 1.0 documents are written in XML. The Atom 1.0 draft of October 2004 on which the following description is based has many similarities to the Atom 0.3 specification described in Chapter 7. XML digital signatures or encryption can be used with Atom 1.0 documents, when appropriate. The following example is a simple Atom 1.0 document:
2004-12-15T18:30:02Z John Smith
http://www.XMML.com/blog/2004/12/15/atomslow.html 2004-12-15T18:30:02Z As you can see, the structure of an Atom 1.0 document is similar to that used in Atom 0.3. The XML Declaration It is recommended that Atom 1.0 documents have an XML declaration. The feed Element The feed element is the document element of an Atom 1.0 feed format document. It has a required version attribute. And it must have a namespace declaration specifying either the default namespace or associating a namespace prefix with the Atom 1.0 namespace. When the specification is complete, the allowed values of both the version attribute and the namespace URI for the Atom 1.0 namespace are likely to change. 132 Chapter 13

has been discussed, but looks unlikely to happen because a significant proportion of those participating in developing the Atom feed format see RDF as not having a sufficiently advantageous complexity-tobenefit ratio. The likely lack of RDF support in Atom 1.0 means that RSS 1.0 is the only viable option for a format for feed creators who want to make available the additional metadata that RDF can provide. Perhaps, in time, Atom 1.0 and RSS 1.0 will be the dominant information feed formats. Atom 1.0 will be used by those who choose not to have the complexity and rich metadata of RDF; RSS 1.0 for those who choose to use RDF. The Standards Body Aspect None of the various versions of RSS have been developed under the auspices of a widely recognized standards body. That reality hasn t prevented the various versions of RSS from being widely adopted in information feeds. However, some in the information feed community believe that standard specifications shouldn t be in the hands of individuals. The decision to develop Atom 1.0 under the auspices of the IETF was, in part, influenced by that perception. At the time of writing it remains uncertain how well Atom 1.0 will be received. A significant factor will be whether the authors of blogging software will adopt Atom 1.0. If the big hitters, such as Movable Type, all select Atom 1.0 (as it looks likely Movable Type will), then the number of Atom 1.0 feeds could increase rapidly. Blogging software and similar products now create most feeds automatically. Whether the number of feeds using various versions of RSS will decrease is much less certain. If somebody produces an RSS 0.91 feed and it is processed correctly by many or all of the major aggregators, what incentive is there to change to Atom 1.0? What Is Atom? Atom 1.0 consists of both a feed format and a publishing protocol. In addition there are draft specifications for autodiscovery of Atom 1.0 feeds and for notification of updated feeds. Each of these aspects is discussed in the remainder of this chapter. Further Information about Atom 1.0 Due to the stage of development of Atom 1.0 at the time that writing of this book is being completed, it is certain that at least some changes will be made in the specifications. The following resources are listed so you can have access to up-to-date information. If you are interested in Atom 1.0 you will want to access online information that updates the material in this chapter. Currently, you can find links to some key Atom documents at http://www.ietf.org/ ids.by.wg/atompub.html. Links from that page may be more up to date than those given here. If the preceding URL returns a broken link at some future date, a likely way to find up-to-date Atom 1.0 information is to use the keyword search located at http://search.ietf.org/ and search for Atom. 131 Looking Forward to Atom 1.0

Why Another Specification? If you have been following the development of information feeds over the last four or five years or have read the descriptions in this book of the development of the various information feed formats, one question that may occur to you is, Why another specification? This section addresses that question. Aiming for Clarity One issue that has drawn the attention of some RSS tool implementers is that the specification documents are ambiguous in places. That is an assessment we can sympathize with, having had to work through the RSS specifications to write the preceding chapters. Because of these ambiguities, developers who write aggregators have to be permissive in the structure of markup they accept. Allowing for multiple formats and, possibly, errors in document formats means that aggregators are less easy to write and may be slower than might otherwise be necessary. For the end user, the ambiguities in the specifications are unlikely to be an issue. The developers who create aggregators write the software so that it accepts almost any markup that reasonably resembles what the relevant specifications seem to say. If Atom becomes the standard information feed format then, over time, aggregators might be slimmed down so that they only accept feeds expressed in one universal format the Atom 1.0 format. At least that s what some hope. In practice, particularly in the short term, Atom is likely to add to the complexity caused by there being multiple information feed formats. Atom will simply add a little more complexity to the mix. Archiving Feeds One of the other areas where improvement is sought over RSS 0.9x and 2.0 relates to the issue of archiving information feeds and their contained items. The idea is that for some information it is important to archive the feed. If you archive a feed in what might possibly become a huge, global archive the need for a truly unique identifier for information feeds and their items becomes more of an issue. The vagueness of the RSS 2.0 specification regarding the guid element for example, becomes unacceptable, if you assume that uniqueness will need to be global and stretch over long periods of time, perhaps years or decades. The assumption that information feeds and their contents are of temporary interest only is a notion that some at the heart of Atom development reject. The notion of archiving feeds is different from the idea of storing information discussed in Chapter 5. Atom 1.0 intends to archive information about the feed itself and the items in the information feed. Chapter 5 referred to storing information that was accessed from a feed. In that context the feed itself was seen as disposable but the information resources that you could, as a user, access from the feed might be of lasting interest. The RDF Issue One of the issues that, in my opinion, means that it is unlikely that Atom 1.0 will ever be the single information feed format is the likelihood that it won t use RDF. The use of RDF in the Atom 1.0 feed format 130 Chapter 13

13 Looking Forward to Atom 1.0 At the time of writing the Atom 1.0 specification is under active development at the IETF. The RSS specifications all have some degree of ambiguity in the specification documents and they all attempt to be backwards compatible with their precursor formats. One of the intentions of the Atom effort is to improve the quality of the specification documents. Another is to create an information feed format free from a need to conform to earlier specifications. However, Atom 1.0 aims to go beyond simply creating a tidier, better specified feed format. It also includes the development of a protocol that can be used by blogging and similar software to update server-side resources in a standard way. The aim of the information feed aspect of the Atom activity at IETF is to create a widely accepted Atom format that would be treated as a standard, perhaps the standard, in the information feed space. In that component of the Atom project, Atom 1.0 resembles RSS 2.0 and, to a smaller degree, RSS 1.0. The Atom 1.0 feed format, like Atom 0.3, is written in XML. The Atom 0.3 specification was a foundation for the development of Atom 1.0. At the time of writing some changes have been made from the document structure of the Atom 0.3 format, with further changes possible. The Atom Protocol was designed to be a standard way for blogging-related software to communicate to a server edits made in content and in a corresponding information feed to the server from where the Web pages are requested and the information delivered. In this chapter you learn: . Motivations for an additional feed format specification . What Atom 1.0 is . What the document structure of the Atom 1.0 feed format may be . About the other aspects of Atom 1.0 The description of the Atom 1.0 feed document structure described in this chapter is subject to change. The description in this chapter is based on the October 2004 draft of the Atom Syndication format located at http://atompub.org/2004/10/20/ draft-ietf-atompub-format-03.html.

A typical namespace declaration for the blogChannel namespace is: xmlns:blogChannel= http://backend.userland.com/blogChannelModule The following elements are in the blogChannel module: . blink: This contains a URL that links to a blog that the author of the information feed wants to promote in some way. . blogRoll: This contains a URL that specifies the location of an OPML (Outline Processor Markup Language) file containing the blogroll for the information feed. . changes: This contains a URL that specifies the location of a changes.xml file. The idea behind the changes file is that bandwidth use may be reduced. . mySubscriptions: This contains a URL that specifies the location of an OPML file containing the subscriptions of the blog author. Whether or not an extension module is supported can vary from one aggregator tool to another. A quasi-official list of RSS 2.0 extensions is maintained at http://blogs.law.harvard.edu/tech/ directory/5/specifications/rss20ModulesNamespaces. Examples include Danny Ayer s Simple Semantic Resolution module and Joe Gregorio s Comment API. Summary RSS 2.0 adds the use of XML namespaces to the document structure of RSS 0.9x. It does not use the RDF. New elements add information about the software creating the feed, the author of the feed, and the location of a comments page for the information feed (a facility used primarily when the information feed relates to a blog). In this chapter you learned that: . RSS 2.0 uses XML namespaces. . The document element of an RSS 2.0 document is the rss element. . All information in an RSS 2.0 information feed is contained in the channel element. . Information feed items are contained in item elements. OPML, Outline Processor Markup Language, is an XML language that can express the structure of an outline. In the context of information feeds, an OPML document is often used to contain a list of information feeds to which a blogger subscribes, the so-called blogroll. 128 Chapter 12

60 Wrox.com P2P Community Blogs
http://p2p.wrox.com/blogs_author.asp?AUTHOR_ID=22322 Copyright (c) 2000-2004 by John Wiley & Sons, Inc. or related companies. All rights reserved. en http://p2p.wrox.com/images/p2p/wrox_rss_logo.gif
http://p2p.wrox.com/blogs_author.asp?AUTHOR_ID=22322 36 31 Firefox 1.0 is available now for download from http://www.mozilla.org.

It downloaded quickly for me, although that could change as the servers get busier, and it installed smoothly.

If you haven t already spotted the new functionality to add a live RSS or Atom feed to your Firefox bookmarks using the button at the extreme bottom right of the Firefox window give it a go….
Tue, 9 Nov 2004 12:01:11 GMT http://p2p.wrox.com/blog.asp?BLOG_ID=37 http://p2p.wrox.com/blogs_comments.asp?BLOG_ID=37 The example document contains only one item and it does not use all of the many optional elements that the RSS 2.0 specification allows. Hopefully, it will give you an impression of what a simple RSS 2.0 document is like. RSS 2.0 Extensions The RSS 2.0 specification does not say much about extensions. All extension elements must be in a namespace (all RSS 2.0 elements are in no namespace). It is not clearly specified that extension elements can be inserted anywhere in an RSS 2.0 information feed document, but this seems to be the most likely meaning of the specification. The blogChannel RSS Module In the month following the release of the RSS 2.0 specification, Dave Winer issued a document relating to the blogChannel RSS module. The document is located at http://backend.userland.com/ blogChannelModule. It is intended to relate to the context of a blog which has an associated information feed. 127 RSS 2.0: Really Simple Syndication

The item Element The item element may occur any number of times in an RSS 2.0 information feed document. Its child elements are described in the following list. The specification is unclear about whether or not these child elements are required. In practice, you can use which child elements you want and omit those you don t. There are theoretically some situations in which you could be in conflict with the wording of the RSS 2.0 specification but this won t arise with real-world items with a title and at least some content. . author: This contains an e-mail address for a person with responsibility for authoring the content of the item. . category: An item element can have multiple category element children. The content of the category element is information about a category into which the content of the item may be assigned. Each category element has an optional domain attribute, the value of which may specify a taxonomy to which the content of the item belongs. For example, in an item about XML the domain might be markup languages. . comments: This contains a URL of a Web page where a user can enter comments about the item. . description: This contains a summary of the item or, in the case of items with a relatively small amount of text, might contain the full text of the item. . enclosure: This contains information specifying a media object associated with the item. This is an empty element with three attributes. The url attribute contains a URL from which the media object can be retrieved. The length attribute specifies the size of the serialized object in bytes. The type attribute specifies the media type of the object. . guid: This contains a value that uniquely identifies the item. The RSS 2.0 specification does not specify rules intended to achieve uniqueness. One typical approach is to use a URL from which the item can be retrieved. In that situation the guid element is likely to have an isPermaLink attribute with a value of true. . link: This contains a URL that can be used to retrieve the full text of the item. When the item contains its full text in the description element, the link element is optional; otherwise, it is required. . pubDate: This contains information about when the item was published. It includes both date and time components. . source: This contains information about the channel (perhaps on another site) that the item originally came from. It has a url attribute that contains the URL for the source information feed. The content of the source element is, typically, the title of the feed. . title: This contains a title for the item. An example item element is shown in the following example RSS 2.0 document. An Example RSS 2.0 Document Having looked at the individual parts of the document structure of an RSS 2.0 document, you can now take a look at a sample RSS 2.0 document that happens to contain my first author blog post on Wrox.com. 126 Chapter 12

. link: The value of this element is a URL representing the feed or Web site. . title: This describes the image. If the feed is being rendered as HTML, the content of the title element may be used as the value of the alt attribute of the img element in HTML/XHTML. . url: The content of this element is a URL that specifies the location from which the image can be retrieved. The link element, a child of the image element, is required, although it seems simply to duplicate the content of the link element child of the channel element. The RSS 2.0 specification is not clear about the consequences should these two link elements contain different URLs. There are three optional child elements of the link element: . description: This contains a short description of the image. The specification suggests that it be used in the title attribute of the link in the corresponding HTML. . height: This contains the height of the image in pixels. . width: This contains the width of the image in pixels. The cloud Element The cloud element is a child element of the channel element. The attributes of the cloud element are used to specify a Web service that implements the rssCloud interface. A useful way to look on a cloud is as a Web application. A cloud acts as a central coordinator for subscriptions to an information feed. Instead of an aggregator polling a server at specified intervals (often hourly) the cloud (the coordinator) informs subscribed users when a change has taken place. A cloud element would appear similar to the following markup: The textinput Element The textinput element allows a user to enter text to be sent to a server-side process, such as a CGI script. Some people question the appropriateness of the textinput element, seeing that such functionality belongs more appropriately inside an individual Web page. . description: This contains a short description of the text input area. . link: This contains a URL which specifies a server-side process, for example a CGI script, to which the text entered by the user is sent. . name: This contains a name for the text in the text input area. . title: This contains the label for the submit button associated with the text input functionality. 125 RSS 2.0: Really Simple Syndication

This document is of little value in an aggregator because it contains no item elements. Surprisingly, the item element is optional in RSS 2.0 although, in practice, a typical RSS 2.0 document will have several. The following elements are optional child elements of the channel element. Some elements, which have their own child elements, are discussed further following the list. . category: This element contains information about the categories of information contained in the information feed. There can be several category elements as child elements of a channel element. . cloud: This element has several attributes that contain information specifying how a connection can be made to a cloud, allowing subscription to an information feed to be always up to date. . copyright: This contains copyright information relating to the feed. . docs: This contains a URL pointing to the RSS 2.0 specification. . generator: This contains information about the software that was used to produce the information feed. . image: This contains information so an aggregator can locate an image (in GIF, JPEG, or PNG format) to display in connection with the information feed. . language: This contains a two-letter language code, with optional extensions. Example values are en and en-us. . managingEditor: This contains the e-mail address of the contact for queries about editorial content. . pubDate: This contains the publication date for the feed. . rating: The PICS (Platform for Internet Content Selection) rating for the channel. . skipDays: This contains information indicating to an aggregator the days of the week when a feed is not expected to be updated. . skipHours: This contains information indicating to an aggregator the hours when a feed is not expected to be updated. . textinput: This displays a text box to allow the users to input information for processing on a server, typically (if the textinput element is present) on the server from which the feed originates. . ttl: This contains information about the period of time before the aggregator should check for new content. . webMaster: This contains the e-mail address of the contact for queries about technical issues relating to the information feed. Several of the previous elements are shown in the example RSS 2.0 document later in this chapter. The image Element The image element specifies an image that can be displayed along with the channel in an aggregator or other user agent. The image element has the following required child elements: 124 Chapter 12