Puzzlepieces – tag ‘xml’

In my last post was my initital reaction to this new API from Google. It’s not surprising that I’m worried about Google’s plans here, as their record on XML cooperation hasn’t been all that stellar. I haven’t fully looked into it yet, but I had noticed Google’s absence from a new standardization effort; Retailers, Engines Want Standard for Product Description (via Gary) lists MSN, Yahoo!, and others.

Anyhow, getting down to the real point, I’ve decided to completely skip over “What Google Should Have Done,” and go right ahead to “What Google Should Now Do.” Save myself the wasted keystrokes.

Step 1: Fix Feed Refresh Interval

Remove the refresh-interval attribute from <feed>. Add it to RSS/Atom in a namespace. This shouldn’t really change anything. This has nothing to do with OpenSearch by the way, it’s just my general opinion on XML - extend an existing format rather than creating a new one.

After I started writing this, DeWitt posted his take on it all: Google Toolbar, Custom Buttons, and OpenSearch. It includes a lot of what I was going to say, so I will continue my comments as a reply to his post.

A final note, for anyone that’s counting… this makes at least four different Google products that are RSS/Atom readers (Google Reader, Google Toolbar, Google Personalized Homepage, Google Desktop). I hope they’re all using the API that the Google Reader team has been developing.

Google Toolbar API - Guide to Making Custom Button - aaaargh. I see Google’s recreated the OpenSearch Description format. Nice job guys. Oh yeah, and it also functions as an RSS feed information thingy…. which as far as I can tell, only provides refresh rate…. if they need that so badly they could make that element an extension to RSS/Atom.

It seems like Google’s attitude nowadays is “developers like APIs, and they like XML, so lets create lots and lots of little tiny APIs and new XML formats.” How about a new search API, like for images. The web search API was last updated years ago… . Oh, in case we’re counting, Google now has created XML formats for sitemaps (but they accept RSS and Atom, so what was the point?), homepage modules (why not use HTML, as I’ve written before?), “buttons” (Google Toolbar), 50 (exaggeration) kinds of microcontent (Google Base), etc.

More later when I get back from school and have time to look into this more fully.

Yes, this makes two blog posts today, and yes, I’m going to talk about XML again.

I’ve suspected this for a while, but hadn’t looked into it. Thanks to Sam Ruby, I see that someone has: Who knows an XML document from a hole in the ground? shows that indeed, a lot of RSS/Atom parsers are not reading XML as XML… or at least, they’re not understanding the namespaces.

This wasn’t a problem when most feeds were bare-bones, and before Atom. Now, only a couple of years after I expected, all sorts of data and metada is starting to be put into feeds, with lots of different namespaces.

This is one of those things were if you’re a feed reader, and you don’t understand namespaces, you are broken, and need to be fixed. There’s no way around it, end of story.

That being said, I’m much more optimistic now than I was about those fixes actually happened. Phil Ringnalda’s Atom title tests really did help and pushed a lot more readers into supporting it properly. Now let’s see some real XML parsing.

Tim’s two recent pieces are just fantastic: On XML Language Design and Don’t Invent XML Languages. I was originally going to take out some points, and comment that I agree with them and why, but Tim makes a lot of points, and I didn’t see any that I didn’t agree with. A lot of them are things that I considered very important when I was working on OpenSearch.

I will make some specific comments about OpenSearch though.

Tim suggests to generally avoid making new versions, but to be extensible instead. Absolutely. OpenSearch 1.0 was nice, but it was still relatively new, and not all parts were extensible, although some of it certainly was. OpenSearch 1.1 is very extensible; i.e. everything is. While I would be the first to agree that improvements could be made, I don’t think they should be, not for a while.

As Tim points out, developers don’t want a moving target. I really believe the 1.0 to 1.1 changes were necessary, and there wasn’t a huge amount of 1.0 software made. As much as can be added or improved, I would say not to do any of this until developers start to actually take advantage of the existing features. Few people realize how cool 1.1 is , and like RSS, I think it will take years for people to fully realize it.

Tim says that XML languages should all have a validator, and I agree. I’m hoping Sam Ruby and/or the other Feed Validator developers will add OpenSearch, once 1.1 draft 2 is declared the final version.

On a related note, Tim links to this list of XML languages and I don’t see vCard there - is this just because we normally think of vCard in its pre-XML form?

I’m hoping Tim Bray and others will catch on - there’s some really neat stuff going on in the OpenSearch format, which is, of course, RSS/Atom. Except for the Description file

Someone please explain to me why the Google Homepage API is a small XML format that includes an HTML bit, instead of just HTML itself?

Okay, so they introduce a few bits of meta data. The links, such as screenshot can be handled by <link /> with rel=”screenshot” and such. The other bits of data can be handled by <meta />, except for the title… there’s already one of those in HTML

Note that I haven’t taken a good look at any of the Microsoft Live Gadgets, Google Sidebar API, Yahoo! Widgets (Konfabulator), or Dashboard.

I’ve been hard at work at A9.com, working on the OpenSearch website.

Here’s some of what’s new:

OpenSearch 1.1 Draft 2

The first draft went up in September - hopefully the second draft will become final within a few weeks. A9.com already supports it. The biggest change since the first draft? A fourth component to the specification: OpenSearch Query which allows you to reference a query. It may not sound like a big deal, but I think it is. Right now you can use it to provide spelling suggestions, related searches, etc. to A9. While not yet supported by A9, it allows for any of search parameters to be used - so it can establish a dialog between an opensearch producer and consumer using extended search parameters, even if the consumer doesn’t know anything about them. Another change is the addition of autodiscovery - imagine doing that with search tools!

Improved documentation and developer resources

New and/or improved: General FAQ, Developer FAQ, Developer How-to, specification changelog, guide to upgrading from 1.0 to 1.1, an index of elements and attributes, general tips. There are also listings of tools/software for producing and consuming OpenSearch feeds. This includes an OpenSearch-to-XHTML stylesheet (XSLT - very comprehensive), a converter for any XML into OpenSearch, and a converter from Sherlock plugins (used in Firefox).

Mailing List

OpenSearch isn’t called “open” for no reason. And to further that cause there is now a mailing list for discussing the specification, software for reading and writing it, etc.

That’s the gist of it. Although it isn’t yet, I think OpenSearch is very much on the road to become ubiquitous, just as RSS/Atom is becoming so. The support by Internet Explorer 7 gives that a huge push.

It’s amazing that I’ve been given the opportunity to put so much work into an open format, that benefits the entire industry, not just A9.com. You can be sure I’ll be saying more about OpenSearch in the future - if not in this blog, then on the mailing list, on other blogs, etc.

And for those who have no idea what I’m talking about - the homepage of the OpenSearch website is hopefully much clearer now at explaining it

I was thinking of a really long rant, but instead I’ll make a short comment.

Google Base leaves me with a bad taste in my mouth, in more ways than one. You?