Publishing options

If you create a web page using XHTML and mark it up so that it's divided into semantically meaningful components, then that web page can be used as a basis for publishing the content in other formats, too. It sounds reasonable enough, and yet the very suggestion has attracted a huge swarm of controversy in the past day or two.

I innocently stumbled into this controversy yesterday when I noticed and commented on an entry in Sam Ruby's blog. When I first decided earlier this year to publish an RSS version of this blog, I adapted Julian Bond's RSSify program, and in the process stumbled upon the concept of marking up different elements using the "id" attribute. I've since discovered this to be very handy, since I can now write short PHP scripts that screen-scrape the content from the original page and repurpose it for use elsewhere, for example to rebuild the home page each time I make a new posting.

The next step — which I have in hand — is to adopt a formal XHTML page structure that can be used in this way (and others) as a means of managing the content throughout the site. Hence my comment on Sam's blog, which is really a plea to hear whether anyone has begun to codify CSS class names for content management purposes (Sam originally wrote "for aggregation purposes" but that's more limited than the usage I have in mind, and either will achieve the same result).

Probably the reason no-one has done this before is that most sites using XHTML are storing the content in a central repository and using XSLT to transform the original into web pages, RSS feeds and so on, from source. But I like the idea of surfacing this structure to the web page itself because you can then open it up in a more loosely coupled (ahem) way to less sophisticated repurposing mechanisms (which I instinctively prefer because they're likely to be more evolvable).

Note that the point here is to make it easier to repurpose the content to new uses, rather than to eliminate the need to produce a separate RSS feed, which to my mind is the pursuit of technical elegance gone mad. I want the content of this site to remain useable long after RSS and HTML and whatever else comes along have become obsolete, which means that it makes sense to build transformability right into its core structure. That way I can transform it into as many redundant formats as I like, and in doing so allow the content to reach the broadest possible audience.