Conclusion

We have demonstrated how TMSS can used as channel representation in a standalone mode or alongside with RSS. While the developed packages are good for experimentation, they are yet too slow for a production site.

One might justifiably argue what the merits of yet another notation is as it does not make the life of a webmaster easier and RSS is proven to be working now for several years. One answer to this is that TM-based application servers will need a channel representation in Topic Map form in any case if they want to merge the content with an existing map. Another answer might be that - using Topic Map technology - the inclusion of additional vocabularies and more meta data is done within the model using simply more maps merged into the channel.

What we found more interesting, though, is that the constraint language provides an excellent means to control the nature of what is being syndicated. Two syndicators might decide to start off with TMSS using the set of constraints as part of their contract. At any time the partners might change the constraint rules, either relaxing or extending them. An example scenario would be to send the original TMSS channel information but now enriched by background information about the articles, about the authors, about related material. If both syndicators can process these maps, the changes in the applications can be rather minimal. If the original TMSS information is still there, they also maintain backward compatibility.

This opens a field of syndicating highly structured content, TMSS being just one such structure which happens to be compatible with RSS.