"Don't you have it set up so you can just automatically pull our listings from our Web sites?" the e-mail asked.

"Not yet," I typed in my response. "But it's a great idea, and I'm working on it now."

My correspondent was the head of an organization that is a member of a five-state performing arts presenters association, a 50-member group whose Web site I have managed for the past five years. The association is made up of community and university organizations that bring touring opera, dance, theater, and music to their respective locales.

Sharing information about one another's offerings has always been an important component of the group's activities, not only to keep abreast of what's going on in the region, but also to be alert to possible cooperative routing of traveling attractions.

As any of you who work with such groups know, a consortium of nonprofits is likely to include members with a diverse range of monetary resources, staff, and technological sophistication. So any technical solutions introduced to the group are likely to be adapted in steps or stages, and must be inviting even to organizations with small resources.

There had been some attempts to create a group calendar that included events from the various member organizations, including - in the early days - having a volunteer hand type from member brochures into a spreadsheet. Even that low-tech approach was hit or miss, as some organizations neglected to mail their brochures to the poor soul doing the compiling!

About three years ago, when the last of the member organizations finally added their own local Web sites, I instituted a grouped search feature for the members, which used the free search facility offered by Atomz (www.atomz.com) to crawl the calendar listing pages of the various member organizations' Web sites. This didn't create a single set of compiled listings, but it was at least beneficial to members wishing to see which of their colleagues might be presenting an attraction in their area of interest. I also have Atomz crawl an archive of the group's list serve e-mail so members can track mentions of artists and attractions that are still prospective and for which tours might still be building.

It was probably the Atomz search my correspondent meant when he expressed a recollection that we were "automatically" pulling listings from his Web site. But, as valuable as that service is to us, it is not creating an aggregated calendar of event listings.

The means to create an aggregated calendar are readily at hand, though. If each organization could output commonly formatted XML, these outputs could easily be combined into a single group calendar. And, if a group like ours developed a protocol for sharing this information, it could likely be useful to others.

I proposed to my group that we undertake to create what we're calling performing arts event syndication (PAES). The leaders of the group told me to set up a framework to do it.

As luck would have it, I also have as a client a consortium of performing arts presenters in one of the states that is part of the big group. This client has a couple of members large enough to also be members of the multi-state group. The single-state group already has a combined calendar of their events, entered through a simple back end. I realized that if I could generate XML from the single-state Web site for each of its members, I could turn around and capture the XML of the two members of the multistate group, for the multistate group's aggregate calendar. In other words, I could provide my own early adopters!

RSS: Weblogs, News, and Why Not Performing Arts Events?
As a blogger (http://poorclio.com), I was aware of the growing use of RSS for Web log feeds as well as news feeds. I reasoned that there would be an advantage to making the first version of PAES conform to an RSS standard, so I chose RSS 2.0. In fact, the project was begun simply by using the RSS 2.0 protocol, relying at this stage on participants observing a couple of simple conventions in their RSS in order to comply with the formatting of the aggregate calendar.

In fact, one of the benefits I planned to tout to all parties involved was the value of having an RSS output that end users might subscribe to in their own news readers. In the future, our project may call upon us to create a more refined or specific protocol for PAES, in which case our members are likely to simply output both; but for now, in these early stages, we can demonstrate and build the project with RSS.

Because my background was in the newspaper business, I also envision that a publisher creating a community arts or events calendar might one day compile such listings by crawling the XML URLs of the organizations in the coverage area. Once again, though such an application might evolve its own specialized protocol, RSS seemed as good a starting point as any to demonstrate the concept.

Additionally, there is a wealth of resources available online to assist someone wishing to output RSS, in most cases specific to any of the various application servers. And, of course, there are RSS validators easily accessible on the Web.

So I was ready for the first step. Within my own client base I had a single-state group that had a couple of the organizations that would feed the multistate calendar. Why not create an RSS feed for all of the organizations in the single-state group, and then feed the two who were members of the multistate group into the aggregate calendar? This would have the side benefit of providing an RSS feed for all of the members of the single-state group, most of which aren't members of the multistate group - and which tend to be smaller organizations unlikely to have the technological resources to be out front on an issue like developing RSS feeds on their own. I could feed my own project, and also do a good turn for the members of my single-state group.

Step One: Creating Some XML That Will Later Be Aggregated
The single-state group's Web site features a calendar of events displayed in a monthly grid calendar format, identifying events by type, city, and date. A link under each event leads to a detail page with information about the specific event, as well as the presenting organization. The database is MySQL, and the site is written in ColdFusion. The information about the events is in one table, and, for the detail pages, is joined to a table of information about the member organizations.

The table for the events is sufficient in this case to generate the information needed for our RSS output. After finding some good resources on the Web, I created a template (see Listing 1) that loops over each organization, checks to see if it has any upcoming events, and then loops through those events and writes them to an XML file.

While these XML files are valid RSS, you will note a couple of interesting things about the way dates are used. The date is actually found twice, once as part of "description" and once in the "pubDate". Also, you will note that in this case "pubDate" - unlike most RSS - is not the date the information was generated, but rather the date that the event will occur. This allows the "items," once passed into the collective database, to be sorted on the "pubDate" date. Also, if the XML is displayed in aggregators (which sometimes do not show the pubDate), readers will see the dates.

It is also worth noting that the event time is not necessarily carried by the date/time object that becomes the pubDate. My observation of the manner in which many of the member organizations of the multistate group set up their own databases led me to avoid relying on that date/time object to carry the event time. Many organizations use only the date portion for parsing event order and use a text field for the time, possibly to allow for non-time designations such as "immediately after the performance" or even "TBD." In any case, practical experience indicated that I might have better success if I planned to rely on the event date and time to be passed through as text in the description field.

Eating What I Cooked...
Now that I had a couple of RSS feeds of calendar information tailor-made to my needs, it was time to capture them and aggregate them into a single calendar on the multistate organization's Web site. The template I wrote for doing that was made easy by ColdFusion MX's XMLParse() function (see Listing 2).

The first thing I do is remove all earlier entries into my aggregated listings, which are in a table called XMLEvents. Then I poll the table that has information about the members of the organization, and select those that have an XML output (and also have paid their dues!). Using CFHTTP, I loop through each of them and collect the wanted XML from the designated URLs, and distribute the parsed XML into a CFQUERY insert that populates the events into the XMLEvents table. If there are errors, I generate mail, and also show error messages on screen for any time that I call the template from the browser.

The template is scheduled to run every day, and the result is a set of similarly formatted event listings that can be sorted on date and displayed in any variety of chronological renderings.

... and Getting Someone Else in the Kitchen
Now that I had demonstrated that I could complete the circle on my own, it was time to start to make it work with the participation of the member organizations of the multistate group. Since I knew that roughly half the members had Web sites employing application servers, and that several different application servers were represented, I created a "helper" page for webmasters with links to sources of information about creating RSS with ColdFusion, ASP, JSP, PHP, etc. (see Figure 1). I also provided a link to an RSS feed validator, and a feed test that lets a webmaster see how his output compares to a model output.

I sent an e-mail to the multistate group's list serve, which goes to the executive directors, asking them to have their webmasters take a look at the project and contact me with any questions they might have. The first response came from a member organization whose Web site employs ASP; it took the webmaster there about 45 minutes to create the template for outputting the XML, and it's been humming along since (see Figure 2).

A few weeks ago, at the most recent meeting of the multi-state group, it was my pleasure to award a prize (a macadamia nut pie from Hawaii, no less!) to the executive director of that early-adopting member organization. Now, I'm looking forward to having others join in.

The Reality of Small Nonprofits
In my next appeal to members of the multistate group, I'll point out how relatively painless it was for the pie winners to incorporate the XML output into the function of their Web site. The technology side of creating this kind of project is often far less challenging than the organizational behavior, even in a group like the one I am working with, which is relatively progressive in its outlook. (When I first started working with the multistate group, one of the initial emphases was on getting members to use a list serve rather than calling around or sending one another batches of faxes; one of the officers told me proudly, "Honey, I check my e-mail once a month, whether it needs it or not.")

The reality is that the kinds of nonprofit organizations that present performing arts are often lacking in staff and resources, and in many cases are removed from the source of their technological services. In cases like this, I sometimes have greener-on-the-other-side fantasies about being a corporate IT mogul, who I am tempted to imagine simply decides on what shall happen in his empire, and thereby his will is done. Come to think of it, maybe corporate IT guys have that same fantasy!

In any case, the most-likely scenario for my multistate group is that a few more early adopters will join in with their XML at my personal urging, until there is enough traction and momentum that those who aren't in the calendar feel like they are missing an opportunity, and want to join in - even to the point of switching to an application server approach if they're not using it already, in order to be able to participate.

Where From Here?
The benefits of publishing and sharing calendar information through XML are so great that it seems inevitable that arts organizations will all want to do this at some point. The more places an event is listed, the more people will see it, and the more tickets will be sold. Aggregation of events has the additional advantage of placing your events next to other similar events. Search engine visitors and others who find a calendar while on the hunt for say, a dance performance in one city, are good prospects to buy tickets to a dance performance in a second city, even a couple of hundred miles away. Performing arts calendar aggregation groups information by affinity as much as by location.

Additionally, middle users or republishers (perhaps in print, in the electronic media, or on the Web) could be served by having a reliable source of commonly formatted events listings, which could be aggregated and/or transformed through XSLT, etc., as needed or useful.

If a new protocol is developed for these events, either as a stand-alone PAES or as an extension of RSS, it might be able to serve newspapers, chambers of commerce, or other organizations whose mission includes creating aggregate calendars. These calendars may include not only arts events, of course, but other community functions as well. In fact, maybe instead of standing for Performing Arts Event Syndication, one day PAES might be understood to mean Publicly Attended Event Syndication. What greater honor can a technology acronym garner than to have more than one antecedent?