| |
 |
Thursday, May 23, 2002 |
|
Postel's dictum applied to HTML in RSS
In the commentary attached to Ben Hammersley's RSS discussion, someone (whose name got truncated) cites Jon Postel's famous dictum in regards to use of HTML in RSS:
Escaped html in the tag is very common and isn't going to disappear any time soon. So let's make it a convention as RSS creators to be sparing and deliberately strip the more aggressive tags when we create it. As consumers, we should be writing code that strips the tags we don't like and not complain too much when people throw incomplete tables at us. Be lenient with what you consume, be pedantic and accurate with what you create.
I took a run at this problem last week on a plane trip. For a long time now, I've intended to rip out the MS DHTML edit control in Radio, and pop in Ektron's slick eWebEditPro, which I wrote a column about last year. It should be a straightforward swap that would make Radio's WYSIWYG editor able to emit either clean HTML or XHTML, rather than the hideous stuff that MS control spews out now.
Given the amount of writing I do here, I'd be quite willing to pay something for a add-in that would enable me to honor Postel's dictum -- that is, "to be conservative in what you send."
For some reason, though, I went round in circles. Couldn't seem to find the right combination of UserTalk, HTML, and JavaScript to get that Ektron control working in place of the default WYSIWYG control. I'll take another run at it one of these days, but I just thought I'd report the idea in case somebody else wants to go there first.
9:08:52 PM 
|
|
|
Conversant and the art of the press release
The other day I received an announcement, by email, about the release of a version of Conversant, Seth Dillingham's groupware system built in UserTalk and layered atop either Frontier or Radio.
I met Seth a few years ago, when he drove up from Connecticut to introduce himself to me. According to Seth, Conversant's development was much influenced by the ideas in my book, and in particular the synergies between NNTP- and Web-based groupware. I was, and am, flattered.
Seth and I talked again today. He had been wondering whether I saw his announcement, and what I thought about it. Turns out this was an object lesson in press-release writing. It began: "After three years in development, Macrobyte Resources is pleased to announce the release of Conversant 1.0b1." Several things conspired to diminish the effect this announcement should have had. First, the version number -- 1.0b1 -- failed to communicate that this was, in fact, the first release of a deployable Conversant. (Formerly, it had been a hosted service only, but I hadn't known that.) Second, there was no list of new features and benefits, which was confusing given the "years of development" that had gone into what seemed (to me) to be a new version of an existing product, rather than a newly-productized service.
It's hard to achieve an objective mindset when you are a developer writing your own press release. I completely understand how and why this kind of glitch can happen. Maybe this glimpse of how things look when seen through the eyes of a longtime trade-rag hack will be helpful to others.
Conversant, by the way, is interesting in ways that are orthogonal to Radio. It's a server-based product, not a desktop product, and is useful for all the reasons that any featureful and scriptable groupware-and-document-management system is. So now that I've got the story straight...congratulations, Seth!
4:27:12 PM
|
|
|
Zope Page Templates, triangulation, and shared blogspace
Jeffrey P Shell gives us a Zope insider's view of working with ZPT (Zope Page Templates). I'm a Zopista who's yet to take the plunge into ZPT, TAL, and TALES. Jeffrey's essay confirms for me what I've suspected about these technologies:
1. The learning curve (for me) would be fairly steep.
2. The benefits would be substantial if I had to work closely with a GoLive- or Dreamweaver-based designer.
We could further triangulate on this if another ZPT user, ideally one less Zope-savvy than Jeffrey (who used to work for Digital Creations) were to weigh in.
I can remember debates, a few years ago, about whether and how to implement a rating system for CPAN modules. The problem was (and is) that you go to CPAN, find four modules that address some problem, and can't easily figure out which would be right for you without investing a lot of time. A formal rating mechanism is fraught with problems. But the informal triangulation effects that we see happening in blogspace are becoming a Googlish solution.
Jeffrey said a while back, of his blogging experience, "the sense of community hasn't really hit me yet." Understood. It's more of an act of faith than it should be, right now, to put stuff out there as you've been doing.
A next level of organization will happen. Ad-hoc blog registries will surely emerge, around topics like Zope, and will restore some of the architecture of shared public space that we are currently sacrificing in order to make progress in other ways.
Meanwhile I very much appreciate that Jeffrey has opened a window into his always-agile mind. I know others do too.
9:08:06 AM
|
|
|
What is an RSS description?
Ben Hammersley has taken note of a flock of RSS-related rumblings. Here's some commentary on his commentary on my rumblings.
<fullitem> a sub-element of <item>
<fullitem> does for RSS0.9x what mod_content does for RSS1.0. It allows the entire item text to be included in the feed, including entity-encoded HTML markup.
This, to my mind, is where one possible weakness comes in: allowing formatting HTML markup, such as FONT tags, within an RSS feed does allow feed providers to royally mess up aggregating sites. A misplaced *lt;tr> might break much layout, as would a missized font, and so on. My suggestion is to include an attibute that points to a suggested stylesheet:
This fits nicely with the push toward XHTML in ordinary webpages, and seems more elegant. To me at least.
I guess I'd say that <fullitem> does for RSS0.9x what <description> does for RSS0.9x, in a situation where (as is true for my primary feed now), <description> is truncated to less than the entire item.
Sending escaped HTML markup can cause all sorts of trouble, for sure. It's really embarrassing to break other peoples' aggregators with a bum feed, as I've discovered for myself. It'd be wonderful if XHTML writing tools were common. But they're not, and until/unless they become so, I guess the safeguard is the immunological system of blogspace, which quickly punishes offenders.
<blurb> a sub-element of <item>
The blurb element contains a precis of the item, halfway in size between a description and a full text. I would suspect that this might only be used for very long pieces, where the full text is much too full, and the description too high-level.
As I'm using it (in my secondary feed), <blurb> is the truncated item which, in my primary feed, is called <description>.
This is goofy, of course. I did it in part to see if the sky would fall if I added extra tags into my non-modularized feed. (It didn't.)
I'm aiming to offer choice. Rather than always truncating (which disappoints people who like to read whole items in aggregators), or always sending whole items (which disappoints people who like to scan and decide whether to click through), I offer both styles. At the moment, I do this in parallel feeds:
primary feed: <description> = truncated, <fullitem> = nontruncated
secondary feed: <blurb> = truncated, <description> = nontruncated
I'm sure nobody is using either <blurb> or <fullitem>. Personally, I'd rather to combine these functions like so:
<p class="lead">The lead...</p> <p>The rest...</p>
In principle, the algorithm used to truncate (for me: first paragraph; for Eric Snowdeal, the first 500 characters) could be applied within a single instance of the item, without the duplication I've introduced. In practice, I doubt such intra-item coding would work reliably.
I expect that current practice -- either truncating items or not -- will continue. A few people (like me) may bother to offer a choice, in the form of parallel versions. The overhead is no big deal really, XSLT happily transforms one into the other. While aggregators could offer users the choice, within a single feed, of long or short variants of that overloaded thing we call <description>, I doubt this will matter to enough people to get off the ground.
12:30:20 AM
|
|
© Copyright 2002 Jon Udell.
|
|
