Blog posts tagged "design"

Jane Pratt Working for O’Reilly These Days?

December 8th, 2004

I buy a lot of tech books (see One Man’s Attempt to Support Tech Publishing), and generally have a whole slew of (largely uninformed) opinions about them.

Which is why I was kind of surprised when O’Reilly brought out the “Head First” series, and shocked when it was pointed out to to that they are consistently some of O’Reilly’s bestsellers. I can’t help but wondering if it has something to do with their Cosmo inspired cover design?

Tagged: Uncategorized , , ,

New Atom Link Types?

May 27th, 2004

Arbitrary links which are self-describing as to their intent are incredibly cool, and I’m happy Atom offers them using the link constructs plus rel attribute. (I was also a fan of RSS 1.0 mod_link, but the only one apparently) However Atom has some potentially problematic, or at least confusing limitations.

Last week, when I was thinking about Google leveraging the link construct to syndicate Usenet threading, I was rebuffed by the Atom spec which claims:

The “rel” attribute indicates the type of relationship that the link represents. Link constructs MUST have a rel attribute, whose value MUST be a string, and MUST be one of the values enumerated in the Atom API specification http://bitworking.org/projects/atom/draft-gregorio-09.html.

Now Mark is using the ‘via’ type and pointing to LinkTagMeaning as the definite list of rel types.

The Question

So my question is, LinkTagMeaning is a wiki page, does this mean that the rel vocabulary for Atom is open for growth as long as it is documented on this page?

(an aside: The problem with the theory behind trackbacks – that the web is just one large conversation and therefore we don’t need to enable comments – is that I could have written this question as two sentences in the context of Mark’s blog, but its 3 paragraphs over here)

Tagged: Uncategorized , , , ,

Atom Feeds for Usenet

May 14th, 2004

Google Groups 2 (nee DejaNews) is in beta, and available for play.

Among the new features is revival of the option for users to create new groups, putting then squarely in competition with YahooGroups. (btw if you control both the mailing list and the mail account this opens up some cool possibilities, the most boring of which is keeping only a single copy of a message instead of one per subscribers [stuff we chatted about in the context of Riseup])

Now with Atom

However I think the coolest feature are the Atom feeds per group. Just a short 9 years since I’ve stopped compulsive reading rec.arts.books rab has 2 shiny new Atom feeds, recent posts, and recent threads.

An aside, I’ve always thought the argument of the form “there are more RSS 2.0 feeds then any other format so…” were specious, but some people are fond of them. Well with Usenet+Blogger my gut says the total number of Atom feeds is on track to pass RSS 2.0.

Whither the Atom Namespaces?

My critique of Atom is, was, and has always been that it was invented as a weblog syndication format. I brought this up during the initial design process, but the idea failed to gain traction. Its very cool to see Usenet to RSS, but its a shame that this distinct content with its own unique metadata is getting shoe horned into looking like blog posts.

Where are the custom Atom namespaces? (modules in RSS 1.0 parlance) I’ve noticed that as new Atom sources come online they seem to be shy about extending the core, and so some things which should not be forgotten, are lost.

Give me Threads

Google Groups as the definitive source of Usenet over Atom is in place to do some good for the world, and create a de facto standard for this space. As they move into competition with YahooGroups (a service which while popular, hasn’t changed much in the last 3-4 years, except to ad the interstatials, and whose own syndicated offerings suck) they’re going to be one of the largest providers of mailing lists. At the very least threading information would be nice. And if Atom can get it together and offer a decent, cross application threading module, I’ll take back all the nasty things I’ve said about it. (which really haven’t been that nasty) We tried with RSS 1.0 and the ThreadML initative, but it kept bogging down.

I tried to get this stuff into Atom from the start, but didn’t have the time/clout/cabal status to influence. If I was modelling it today I would have used the link element, with a new rel type. Also might be worth checking out the prior art in the space.

Also does Gmane provide RSS feeds? I a quick search this morning didn’t turn anything up. (talk about a candidate for Google acquisition, they wouldn’t even have to change the name)

(Mark agrees that YahooGroups has failed to innovate, and he should know.)

update: Proposal for threading in Atom

Definitive RSS 2.0 feed?

April 8th, 2004

I’ve probably alienated any RSS 2.0 fans who might have once read this site (see train wreck), but my question from January still persists, can someone, anyone, point me at a feed, or set feeds the parsing of which would demonstrate at least marginal RSS 2.0 competence?

Dave’s feed is missing the T and L of the core RSS TLD tripod. Sam’s feed gets a bit esoteric, while a Moveable Type RSS 2.0 feed might be considered politically suspect.

Ditto, does anbody still publish an 0.90 feed?

Anybody got an example feed I can test against? Help!?

Tagged: Uncategorized , ,

Reviews, Dates, and Microcontent

November 6th, 2003

Slowly digging myself out of the back log from a week offline (expect lots of MLPs).

One thing that happened last week was the release of two very rich new modules for RSS (2.0) that are being batted around the Net this week (both via les).

The Reviews (RVW) namespace “is intended to allow machine-readable reviews to be integrated into an RSS feed, thus allowing reviews to be automatically compiled from distributed sources”.

Over at Deanspace (which is doing a surprising amount of interesting hacking) the Datebook Schema Embedded in RSS (DBRSS) is embedding an vocabulary for discussing very complex information about events including recurring events, location info, event planning (tracks and costs), scheduling (rsvp) requirements, and convener info.

It is awesome to see people really pushing the boundaries of syndication, thinking about new and creative applications that can be enabled by sharing more data in more structured ways. Which is why I felt a little odd at the very similar disquiet both these specs caused in me. As I was struggling to articulate it, I found Bitsko’s Is a Feed the right place for your Data? which sum up the unease quite nicely.

Review data has permanence, it has linkability, it has searchability, it has reusability — why is it locked in a syndication feed for use pretty much only by syndication clients?
(this is less true of events, and perhaps DBRSS is less covered by this critique)

Its a HyperTextual World

Bitsko proposes “freeing” the review information by giving it its own url, and syndicating a link to it. I think this is brilliant, the information at the end of the URLs is a real untapped source of descriptive power, which is why I loved Kevin’s proposed mod_link. (though no one else seemed to) Bitsko demonstrates how if you moved the structured data (e.g. a machine readable review) to its own URL, you could link to it transparently from an HTML document, or any of the various syndication formats, well worth a read.

Don’t Forget the People

A while back I started writing an article I hoped to pitch to XML.com on designing RSS modules. I never finished it (and XML.com published so many RSS articles, the market seemed played out) but the central idea of the article (in retrospect) was about striking an aesthetic balance in namespaces between readability, and structure. A good rule of thumb is:
Include just enough information in a feed so that an item could be displayed in a meaningful way without having to fetch the remote resource.

There are a few reasons for this

  • RSS has proven that human readable formats get faster uptake; design for the “View Source” style of learning.
  • Fetching and parsing a remote resource is hard for beginners to do well, like all the neophyte PHP hackers in the world who are just wanting to do something quick.
  • Strikes a balance between current, and future usage patterns

Externalizing Reviews

Taking the Reviews namespace as an example, as I imagine myself trying to use it, I think I would want to at least know the title of book as well as the title of the review. This changes the RSS item to read “I am syndicating a review of this book, more information at this URL” instead of just “I am syndicating a review at this URL“.

I support Bitsko’s idea of giving microcontent a home of its own, but lets not sap all of the semantic meaning out of the feeds while we are at it.

Externalizing DateBook RSS

Similarly the bulk of the DateBook schema could be moved an external resource, and the feed could syndication a link to this resource , and the most basic of event information (which is the idea behind modevent). DBRSS even has the advantage that unlike reviews, there are already a number of calendaring/scheduling formats available, and there is no need to invent a new one. (I’m assuming DateBook schema is something new, the name makes me think of an attempt to XMLize the core Palm calendar, but the fields don’t match at all)

Depending on persuasion you have a choice between iCalendar, RDF Calendar, or xCal.

Transient Metadata

You’ll notice (or at least, I notice) that this is a different approach then what I took with my rough sketch of mod
weather (an admittedly much simpler namespace), where I packed all of the information into the feed.

The difference is current weather conditions (and even forecasts) are about the most transient information imaginable. They are also laden with some of the worst, most obscure formats to ever reach wide circulation. There is no added benefit to giving the current weather conditions for this instant in time a home of its own.

More on DBRSS

I think the story on DBRSS is less cut and dry then RVW, I’ve certainly felt the tug of a richer event syndication format myself, perhaps one less unencumbered by Calsch’s years of work. A couple of quick thoughts that came up looking at it.
  • Durations instead of endtimes is a seductive choice, but I’ve found that if you’re storing your events in a SQL datastore, endtimes are much more useful.
  • Tracks I don’t understand, and seem a little off to me. It seems like an attempt to cram a calendar into an event.
  • Wouldn’t it be better to use a geo vocabulary to describe the location, rather then larding it into your calendaring one?

Tagged: Uncategorized , , , , ,