Structured editing of schema-controlled XML data is a hard challenge to meet. Tools that would make the task easy and natural are nowhere in sight. [John Udell]

Maybe John Udell still hasn't seen Xopus. I can't blame him. We (Q42) don't have a marketing department, and our Xopus site looks like we don't want you to use it. But Xopus does seem to be what John Udell is looking for.

All actions in Xopus are schema controlled. If the schema doesn't allow it, the user can't do it. This doesn't stop with structural actions, like 'can you add one or more Authors to a Book', but markup is also restricted by the schema. Can a user only add bold and italic, or also lists and tables? And if the user can add links, is he then allowed to add a target attribute? This is a big issue for CMSs, where the site designers want to give the site a consistent look and feel, but where the editors keep messing things up.

Another issue is usability and discoverability. Users know how to work with Word. And so Xopus provides the standard Word-like interface, like toolbars, context-menus, and some (not too many) dialogs. But a user must do more than edit some XHTML. For example, the University of Groningen allows teachers to edit course descriptions and other course related data using Xopus. The two options they had before were either teach the teachers to use an XML editor, or build huge amounts of html forms more or less by hand.

But Xopus allows the university to take a much easier approach. The webpages of each course were already built from the XML data with XSL transformations. Xopus uses these XSL files to show the XML data in exactly the same way, only this time the content is editable. So the teachers now have a familiar user interface to edit their data in a familiar layout. And that's not all.

The teacher doesn't even have to know the storage structure of the CMS. If he wants to edit his course, he fires up his browser and he surfs to the webpage of the course. And because the system can recognize the teacher, an extra link appears to edit the course. When clicked, the Xopus toolbar slides in and the course data becomes editable. (Not the whole page is editable, just the parts specific to the course.)

At Q42 we're very proud of this product, and we made it open source and freely downloadable. It works in IE5.5 and up, and we know we can make it work in Mozilla. Only we're missing the financial support to do this. Everybody who knows Xopus thinks this is a shame, and we really want to do it, but the reality of running a business doesn't let us. Just one link to end this story: the online demo.

We're have a big storm at the moment in the Netherlands. Wind speeds of 120 to 130 km/h. I live above a bookstore, and it's sign just came down. Also a large piece of metal roof plating fell down across the street, about 4 m² in size. A surprising number of people are still shopping here, but thankfully nobody got hurt.

Bill Kearney: Look at the dcterms module. Specifically a very nice little element called "isReplacedBy".

Ben Hammersley: Works well for me.

Works for me too. [Sam Ruby]

No. They should not work. isReplacedBy would mean that your website is replaced. Not the feed. Unless you make the element a child or attribute of the rss element. But that would not be in the spirit of modules, but it might be the only 'correct' way.

I like Phil Ringnalda's solution more. The link module is perfect for this. But rel="redirect" has the same problem as Bill Kearney's solution. But the link items from the link module, and the link elements from the head of my website are at the same level. They both describe links from my weblog to somewhere else. So the rel="alternate" I have in my HTML file, could also be used in the RSS feed. But an alternate can never be an automated redirect. An aggregator could only give the user a choice between the alternates with application/rss+xml type.

Not a 'correct' solution in sight. Someone might as well be pragmatic then and create a new module.

As Jon Udell discovered, a solution already exists which is simplicity onto itself. Channel elements have an "about" element which specify where the rss feed can be found. If present and different, then readers should follow. [Sam Ruby]

Only sometimes the RSS 1.0 people seem to forget they're using RDF. Because putting the URL of the RDF file itself in the about attribute is of the channel is incorrect. The about attribute denotes what the statements are about. In this case it should be the same as the link element. F.e. the title in my RSS 2.0 file is “Sjoerd Visscher's weblog”, not “a feed for Sjoerd Visscher's weblog”. A feed describes a webpage, not itself.

Yep. That worked. Now a post with a title... Later: That worked too. This should not be to hard to fix.

This is the first post in a new month. I always got an error with the first post of the month. The theory is that the title is to blame. This post is without title. Let's see what happens.