Alex Milowski asks on Twitter about my thoughts on Skunklink, now a decade old.

Linking has long been thought one of the cornerstones of the web, and thereby a key part of XML and related syntaxes. It’s also been frustratingly difficult to get right. XLink in particular once showed great promise, but when it came down to concrete syntax, didn’t get very far. My thinking at the time is still well-reflected in what is, to my knowledge, the only fiction ever published on XML.com: A Hyperlink Offering. That story ends on a hopeful note, and a decade out, I’m still hoping.

For what it purports to do, Skunklink still seems like a good solution to me. It’s easy to explain. The notion of encoding the author’s intent, then letting devices work out the details, possibly with the aid of stylesheets and other such tools, is the right way to tackle this kind of a problem. Smaller specifications like SkunkLink would be a welcome breath of fresh air.

But a bigger question lurks behind the scenes: that of requirements. Does the world need a vocabulary-independent linking mechanism? The empirical answer is clearly ‘no’ since existing approaches have not gained anything like widespread use, and only a few voices in the wilderness even see this as a problem. In fact, HTML5 has gone in quite the opposite direction, rejecting the notion of even a vocabulary-independent syntax, to say nothing of higher layers like intent. I have to admit this mystifies me.

That said, it seems like the attribute name ‘href’ has done pretty well in representing intended hyperlinks. The name ‘src’ not quite as well. I still consider it best practice to use these names instead of making something else up.

What do you think? -m

I’ve seen lots of discussion for and against link shorteners, but not specifically this line of argument:

Let me grab a random shortened link from Twitter. Don’t go away, I’ll be right back.

http://bit.ly/b1fYi1

OK, that’s six characters in the domain, a slash, and six more characters. 50 years from now, if bit.ly is still in operation, the URLspace will be rather more crowded, and the part after the slash might be eight or nine characters. This is a significant cliff, since most people have trouble remembering more than 6 or 7 things in their head at a time. Thus, one could conclude that 50 years from now, newly minted bit.ly URLs will be less fashionable than those from newer link-shortening services, particularly if more short TLDs come online, which seems likely. In that scenario, fewer and fewer people will use bit.ly, and it will become a resource-pit as costs go up (for more database storage, among other things) while usage drops, an economic trend that has only one eventual outcome, leading to the breaking all the external links relying on this service.

I’ve been picking on bit.ly here, but the same principle applies to any shortener service. In fact, the more popular, the more quickly the URLspace will fill.

The moral: don’t use link shorteners for anything that needs to be more durable than something you’d scribble on a scrap of paper at your desk.

More collected Geek Thoughts at http://geekthoughts.info.

Some time ago, Doug Crockford’s excellent blog pointed me to this page on “excessive DTD traffic” at the W3C. Go ahead and follow that link, I’ll wait…

All the standard templates that show how to construct a basic XHTML page include a public identifier of http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd and often a namespace name of http://www.w3.org/1999/xhtml. As the blog points out, these are not actually hyperlinks, they only play them on TV. Huge quantities of software are requesting these URLs 24×7, putting a load on their servers. Often times this results from unfortunate defaults in off-the-shelf XML components such as parsers.

But what did you expect?

This is the web equivalent of having a front-desk receptionist hand out a stacks of self-addressed, stamped postcards, then complaining about how much mail the company gets from all around the world.

HTTP URLs are great for identifiers on a technical basis: they are based on DNS names and have the important qualities of uniqueness and persistence. But as far as human factors go, they are a terrible choice (though with a great deal of inertia at this point). -m

Spotted under the headline Windows Live Search for Mobile Goes Final, Still Great (like they were expecting it to suddenly plummet in quality?) on Gizmodo. It’s a 114k jar file that runs on my SLVR, where Yahoo! Go isn’t yet available yet, so points for that. Search suggestions show as you type, hugely useful on a klunky 9-key entry situation. They use an interesting UI to hold search results, densely packed–6 down the screen–with a status bar on top, and each search result marquee-scrolling back-and-forth as needed. A detail page can zap you in to map mode or set up a call.

My standard test search–a little offbeat but still plausible–for mead near Sunnyvale produced disappointing results. The meadery within walking distance didn’t show, and of the top 6, two were duplicates. Scrolling down to the 10th result, though, did show an interesting, useful result, albeit 60.15 miles away: Knowne World Meads. I wanted to visit the web site, but here lies another problem: there’s no web integration. None of the search results include a URL or clickable link.

For all the hassle, I’ll stick with Opera Mini and my favorite search engine, thank you. -m

The new Flickr Mobile site is up, joining the recently-launched m.upcoming.org. Notice a trend in mobile URL design here? Expect to see more of this from Yahoo! and other places.

The interesting thing about these URLs is that they don’t end in .mobi. There are technical advantages (cookies) to staying with an established domain name. What are your plans, if any, for dot-mobi domains? -m

Article (with a non-best-practice URL) from seomoz. If you’re into this kind of thing, Web 2.0 The Book has an entire chapter on it. Nitpick: Also note how normal folks say URL, not the even-more-geeky URI. -m

All right, nofollow is officially gone from here, using the DoFollow plugin. Enjoy. -m

when building REST XML protocols. Kimbro Staken. Good stuff. -m

My friend Kimbro Staken has mostly stopped blogging, instead relying on del.icio.us. Several others on my RSS reader are trending similarly.

Until very recently, I was doing the same. For me, posting links is a way of keeping the ‘pilot light’ burning when I didn’t have enough time to do full postings–on del.icio.us, posting a link, writing a short description, and clicking in a few tags takes 30 seconds. One can do it without interrupting whatever task led you to an interesting URL. But only once in over six months was that enough to stir up some discussion.
And discussion is what I want to stir up again, hence more focus on the blog. Thoughts? -m

If you’re like me, you often get email messages with long URLs that wrap, which are a pain to actually get into a browser. Easier on Firefox though:

Go to about:config and change editor.singleLine.pasteNewlines setting to 3 or add: user_pref(“editor.singleLine.pasteNewlines”, 3); to your user.js file.

Excellent! -m

Pronounced “wreck”, as the old saw goes.

I can’t be the only one for whom this document makes no sense, which I mean in the broader sense of ‘how does this fit in to the rest of the world’. Many times, looking at the testimonials gives some idea what’s going on. Let’s see…

…frees Web services from the classic HTTP request/response

Huh?

Many other specifications, such as WS-Trust, WS-ReliableMessaging, and WS-Coordination, leverage this facility…

This calls for a new category, WS-Whatever. Sigh. -m

P.S. Looks like Mark Baker has similar thoughts.