Bob Wyman has made a point of clarifying that Structured Blogging is a thing you do not a format. This is a good point to make, because there has been some strong association between the first release SB-generated metadata format, and the concept of Structured Blogging, itself.
The SB plugins can be (and are being) modified to generate microformats and RDF in addition to the embedded x-subnode format currently supported. I myself am not overly fond of the current implementation of metadata embedding, primarily because I don’t think embedding makes sense with today’s web applications.
Increasingly, generated web content is replacing static pages, especially when it comes to online businesses and personal web sites. There are some applications that generate static web pages, but these are becoming more the exception than the rule. Most web and CMS tools generate dynamic content, as do the majority of commerce-based sites such as Amazon, eBay, and the many stores based on OSCommerce.
Even sites that create static pages, such as those based on Userland’s Radio, MT, or TypePad, do so from dyanamic data and change frequently. The ’static’ in these instances is more of a delivery mechanism than a philosophy of web content. However, as we’re finding, creating or generating static web pages that are fresh and timely, takes resources. As such, pages that are created in a more on-demand fashion are becoming, more and more, the norm. For those times when on-demand paging becomes, itself, a resource hog (such as with syndication feed access), many of the on-demand tools now provide functionality to generate a static snapshot of a page, if it makes more sense to do so.
Regardless of approach, though, the concept behind all these pages is the same: web content that is dynamic.
Because of this increasingly dynamic web, it doesn’t make sense to embed different levels of data, or even uses of data, within the same page. After all, we don’t expect to ’scrape’ a page to provide our syndication feeds; so why would we expect to embed our metadata directly in a page, when it can be easily and simply provided in much the same manner as the syndication feed data.
Take a look at this site. My tool, Wordform (a variation of WordPress), generates the page content based on demand. The page contains posts, comments, and sidebar items that enable site navigation. If I port the SB plugins over to Wordform, when I do my Saturday matinee movie reviews, I could use these the plugins to add a more structured view of the data in addition to the already provided unstructured text.
Now, I can generate the more structured data as microformats, and it might make sense to do so because some tools may only work with microformatted data. I could also use the embedded metadata approach behind SB. However, my preferred approach would be to generate RDF/XML metadata for the movie review, and then just add this to the other metadata associated with the page. To make this data accessible, I only need to add a META link in my header, pointing to an URL the same as the post URL, except with an ‘/rdf/’ attached to the end.
In fact, since it is the same data that generates all three, I could have a META link to the current SB-flavored XML, accessible by attaching an ‘/xml/’ to the end of the URL; provide the same data formatted as RDF/XML, accessible by attaching ‘/rdf/’; and then add the microformatting into the page elements. That way, no matter what the tools want, the data would be available.
This is no different than what we do with syndication feeds. Many people provide more than one type of syndication feed, and depending on the tool, can be accessed from tools just by attaching a ‘/feed/’ to the end of the weblog URL (or post, to subscribe to a post’s comments). Since feeds themselves are nothing more than another view of the page data, it makes little sense to use a different delivery mechanism for metadata then what one uses for feeds.
Best of all, with this approach, the data is formatted specifically for the use; rather than trying to warp and twist one format to meet the needs of all uses. Embedding all manner of data into the web page delivered to a consumer interested in only a portion of it, comes from an outmoded way of thinking. It’s based on the idea that web pages are, themselves, costly to maintain and that the more files one has, the more difficult it is to maintain a web site.
However, dusty web page content comes from a time when BLINK ruled, and the only formatting we had, regardless of use, was HTML tables. Then the only issue on most of our minds was keeping pages up to date–keeping the cobwebs off, as it were. Since we had to do this manually, no wonder we didn’t want to create too many pages.
Now, though, the days of static web pages are over; long live the cobwebs.