Since writing An Introduction to WSIL for O'Reilly, I have been occasionally giving thought to interesting ways this under-utilized specification could be applied.
In that article I said, "In many ways, WSIL is like RSS for Web services. RSS is a file format with pointers to published content that can be syndicated and aggregated. WSIL is a file format with references to published Web services that can be discovered and bound."
I find WSIL intriguing because of its simplicity and lightweight implementation is more RESTful then UDDI. WSIL leaves the processing logic to the developer and makes its information trivial to access creating the potential for innovative and novel applications arise.
More recently I have asserted that RSS syndication feeds are Web services and perhaps the most widely deployed Web services across the Internet. Most RSS feeds have very simple interfaces and backends comparatively speaking. However under the principles of the REST architectural style that the Web was built on, RSS feeds do qualify. Take for instance Joe Gregorio's experiment the RESTLog API, a RESTful XML over HTTP using RSS syntax, and should be able to see what I mean.
These two assertions got me thinking about how WSIL and RSS relate and compliment each other. Since its been over a year since WSIL was introduced with little progress, I have an experimental proposal to make that demonstrates some of the potential I see between Web services and RSS syndication.
If RSS feeds are Web services and WSIL is a format designed to facilitate the discovery and aggregation of Web service descriptions, couldn't WSIL be used to discover RSS feeds?
What I propose is utilizing WSIL to create collections of related syndication feeds (presumably from one site) and links to external collections or feeds in one file. Putting this in weblogging terms, combine RSS auto-discovery and channel rolls into one file format. I've created an initial sample of what this file would look like here.
I won't go into the basics of the WSIL format here. (You can read my O'Reilly article for that.) However the WSIL format was not specifically designed with this usage in mind requiring some additional clarification and guidance.
In my example I point to services (aka feeds) my weblog produces. service.name maps to channel.title and service.abstract to channel.description. service.description@location would be the URI of the syndication feed.
I also include links to syndication feeds based on my own channel roll. Ideally, the link tags (using the location attribute) would point to other WSIL files and not directly to a single RSS feed. The last link that I have commented out is a fictitious one to a WSIL on movabletype.org, but demonstrates what a reference to another WSIL collection would look like. Using WSIL pointers allow applications to discover an entities entire collection of feeds and their channel roll with one additional step. (A future path of exploration is combining "traditional" Web services and syndication feed links in one WSIL file and examining the new dimensions to social networking it may or may not enable.)
This proposal for providing RSS feed and channel roll discovery in a single file works well within the WSIL 1.0 specification, however it could use further refinement that begins to break compatibility with the format in its strictest sense.
The WSIL defines the location attribute as optional. In order for this usage of WSIL to be effective, location is required.
I made several criticisms of the WSIL formats initial design that this experiment illustrates. For instance, while WSIL is extensible using XML Namespaces though this extensibility is limited to the service.description and link blocks. What is lacking is richer meta data facilities in the root inspection. The WSIL 1.0 format only allows for the catch-all abstract to be applied. I propose the use of module such as mod_dublincore and mod_admin be utilized in the root inspection tag. While not permitted by the WSIL specification, it is a valid use of Namespaces. Here is an example of a WSIL file with these module applied may look like.
The WSIL specification defines two approaches to auto-discovering a WSIL file. One is by specifying a standard file location. This added convention would allow aggregators and other agents to being the discovery process by pinging a remote site for the existence of a file. Using HTTP a 404 code means keep looking while a 200 means the application can continue processing. This is a more efficient use of bandwidth and processing then RSS auto-discovery because the application did not have to download and then hack out any XHTML link tags pointing to RSS feeds the associated site has to offer. When multiple feeds are offered, it also saves the agent of additional trips back to the server to retrieve additional information such as the title and description of each feed. (This of course assumes that Dublin Core extensions and other meta data has been properly applied.)
One of my nits with the 1.0 format is that the fixed filename is inspection.wsil rather then conforming to the common naming convention of index.*. I suggest that you use of index.wsil as I have with the second convention to WSIL auto-discovery.
If a WSIL file cannot be located by fixed filename, the specification optionally supports embedded references in HTML documents. This is similar in nature to the way stylesheets and RSS files can be auto-discovered with an XHTML link tag. WSIL misuses the meta tag instead. I propose that implementers use the link as I have.
This notion is still a bit rough, but it is my belief that this approach could blur the lines between RSS syndication and traditional Web services and create the potential for innovative applications to form.
Your comments and feedback are welcome. For those interested in discussing this proposal and other similar topics (Joe's RESTLog experiment, My RSS/XSS profile, TrackBack) I encourage you to join and participate in the mailing list I've recently opened on Yahoo Groups. (I've been meaning to make a more formal and grandiose announcement for the last couple of days, but so this will have to do for now.)
