Categories
XHTML/HTML

Repeating

Dare Obasanjo writes:

Repeat after me, a web page is not an API or a platform.

Versioning APIs is hard enough, let alone trying to figure out how to version an HTML website so screen scrapers are not broken. Web 2.0 isn’t about screenscraping. Turning the Web into an online platform isn’t about legitimizing bad practices from the early days of the Web. Screen scraping needs to die a horrible death. Web APIs and Web feeds are the way of the future.

Consider it repeated. Just because people are using XHTML for their pages doesn’t mean that they’re following any specific data model. XHTML is meant to be both open and loose. As for screen scraping: ew, ew, ew.

Categories
RDF XHTML/HTML

Finger in the dike, thumb in the damned

Sam Ruby has asked people to publish a link to this post about the iTuned RSS 2.0 to generate enough noise to wake the dead. Or Apple, whichever comes first.

I do admire Sam’s persistence in wanting to ensure that RSS 2.0 is and remains a valid syndication format. When asked why we should care, Mark Pilgrim wrote in comments:

Am I the only one who doesn’t think this is such a big deal?

Apple is an 800-lb. gorilla in this space (at least until Microsoft releases an RSS-enabled IE in Longhorn). iTunes is to podcasting as Internet Explorer is to HTML. RSS interoperability, at least as far as podcasting goes, now means “works with iTunes.” Thousands of people and companies will begin making podcasts that “work with iTunes,” but unintentionally rely on iTunes quirks (e.g. Disney’s incorrect namespace). This in turn will affect every developer who wants to consume RSS feeds, and who will be required to emulate all the quirks of iTunes to remain competitive.

Apple has effectively redefined the entire structure of an RSS feed, added multiple core RSS elements, made all RSS elements case-insensitive, made XML namespaces case-insensitive, created a new date format, made several previously required attributes optional, and created a morass of undocumented and poorly-documented extensions… to what was already a pretty messy format to begin with.

Yet what happens when Microsoft does release it’s own version of RSS? Or any of the other numbers of companies attracted to the wealth that is currently buzzing around what was, at one time, a “really simply syndication” format?

After all, the age of RSS is just beginning. Don’t doubt that it’s for real: Microsoft Corp.’s next operating system, the oft-delayed Longhorn, will have RSS built in. The company is even adding a set of technical enhancements to RSS, and giving them the blueprints so anybody can use them.

Why so generous?

Microsoft is convinced that RSS is about to become a universal standard for sharing all kinds of data across all kinds of networks.

Microsoft is convinced that RSS is about to become a universal standard for sharing all kinds of data across all kinds of networks.

RSS is big. If 2004 was the year of the blog, 2005 is the year of RSS. Heck, there’s even an RSS session at the Blogher conference. Seems to me that updating the syndication feed validator is about to become a fulltime job.

During the initial discussion on all of this, Phil asked a question about a proposed extension to RSS 1.0, mod_company, which doesn’t validate as either XML or RDF. I’m not sure what the question was but I think it had something to do with the importance of validation. If it is, I can agree with Phil: validation is important. In fact, so important that the W3C spent years defining a model and an associated syntax that could be extended safely, easily, and most important, validly. In other words: resistant to crap.

Crap. Kind of like what Apple introduced into RSS. Except that unlike RDF, extensions to RSS 2.0 require changes to the validator. And changes, and changes, and changes…probably about 100 million or so dollars worth of changes. It’s a good thing Mark Pilgrim isn’t weblogging, because he’s going to be a busy, busy camper.

Poor Mark, and he doesn’t even like RSS 2.0.

As for the microformat folk’s response to all of this, Kevin Marks wrote the following after hearing about the RSS/Longhorn calendar demo:

Now, being able to subscribe to an event calendar is very handy, but there is a much simpler way – using hCalendar and Brian Suda’s x2v calendar parsing tool.

I adapted the conference calendar page, to add an “hevent” to each session ( with help from Ryan and his hCalendar creator).

In other words, why use RSS 2.0 and a future version of IE, when you can use XHTML and microformats now?

It’s funny, ironic even, that what finally brings together all the semantic web folk–RDF and microformat alike– is RSS 2.0, an XML vocabulary that is neither. Why? Because unlike RSS 2.0 we’re both based on a syntax with an associated model for extensibility that doesn’t require a re-write of the validation tool any time a new company develops a use for it.

“Phil is using XHTML.”

*snore*

“Shelley is using XHTML.”

“Shelley? A chick? I didn’t think women could hack markup.”

“Joe the Candy store is using XHTML.”

“You want I should care?”

“Martha Stewart is using XHTML.”

“Tastefully, I hope.”

“The Guardian is using XHTML.”

“Is Ben going to write about us? Do we have to hate him forever now?”

“Microsoft is using XHTML.”

“Oh darn, we’ll have to re-write the validator.”

“Apple is using XHTML.”

“Apple? Arrggghhhhhh! Saints preserve us! We’re doo-o-omed! Doomed, do you hear!”

However, I admire Sam’s diligence in helping to keep RSS 2.0 alive. No matter how difficult the task will be. Must make Dave Winer tingly all over with feelings of warmth and joy. So I’m answering Sam’s plea, and linking to his posts.

But I draw the line at trying to save OPML.

We’ll tag this post 

Categories
XHTML/HTML

Evil is as evil does

Recovered from the Wayback Machine, where you can see this all working.

When I was overcome with an urge to run through the woods, howling at the moon, like a banshee or some kind of wolf woman (albeit one with extremely short hair), I knew it was time to relegate my little HTML retro to the secondary page.

Marquee is evil

blink is also evil

The FONT tag is evil

This page is full of words that blink and crawl and this makes me EVIL!

Sheep are okay.

Categories
XHTML/HTML

BLINK is back!

Recovered from the Wayback Machine.

Phil pointed to a weblog entry that mentions adding an HTML element just for marking untrusted content in a page. With this, Google would then know not to use any links within that section for page ranking.

The concept behind this new addition is that without getting the page rank boosts, the bad mans would give up spamming weblogs and email lists, and the rest of us could go back to exchanging pleasant civilities with one another.

What an interesting idea. Sort of a page rank BLINK element. I can see it now*:

You can also check some helpful info dedicated to…

*BLINK*

Please check out the sites about…

*BLINK*

You may find it interesting to check out some information in the field …

*BLINK*

But why stop at comment spammers? For instance, I’m really pissed that Dave Winer drove right by my state and didn’t offer to stop in and say hi. Mortally wounded. So I think I’ll just enclose any links to his posts within page rank BLINK tags, because I no longer trust him.

In fact, my job here isn’t to promote other people’s writing and sites– my job here is to promote ME. It is all about ME. So why don’t I just wrap all my posts in BLINK tags, and then I don’t have to worry about doing it individually?

After all, this isn’t generating harm to a site, like Vote Links. We’re not taking away a person’s positive link juice; we’re just denying the person positive link juice. No harm in that.

And there are so many other new elements that we could add to HTML to help Google do its job:

The BUTTHOLE tag. This can be used when linking to a butthole. Then when the person’s page shows up in Google, a disclaimer can be attached to the results saying something like, “Someone somewhere thinks this person is a butthole. Proceed accordingly”.

(Of course, we could also call this the WEBLOG tag — most of us are buttholes to someone at some time or another, or we’re not trying hard enough.)

The SICKOPERVERTPREVENTION tag. This can be used to surround content that contains words that will most likely end up in some sick Google search phrase–words like porn, whip, sex, balls, breasts, and sheep.

The DISCLAIMER tag. This can be used to surround libelous content. Then when you’re sued, you can point to the page and say, “See? I used the DISCLAIMER tag. This means I was only joshin’ when I published the content.”

The SUCKUP tag. This is my personal favorite. Use this when referencing a specific individual who you want to suck up to. It could be anyone, from a rock star to a weblogger who has more link juice then you (that is, if they still have link juice with the use of BLINK). We all know that some folks suck up to other folks, but there’s nothing in the writing to prove it. Now we can remove any doubt that sucking up is happening.

Best of all, when the individual searches in Google for people who are sucking up to them, they’ll get back your page. Think of the miscommunications this can prevent?

HTML could get a bit messy with all these BLINK, SICKOPERVERTPREVENTION, DISCLAIMER, SUCKUP, and so on elements — but we just helped eliminate FONT through the use of CSS. Plenty of room for new growth.

Of course, there’s always spoil sports in any grand idea. You know who I’m talking about: they’re the ones who think that adding to the underlying specification in order to accomodate one specific application could lead to markup bloat. Yeah, and they probably also think that the bad guys could route around these new elements anyway. No f**cking fun. (We also need a CONTAINSBADWORDS element, too, now that I think on it.)

Personally, I think we should just BLINK away these naysayers.

*All text examples are from actual comment spams filtered by my absurdly simple and amazingly effective comment spam moderation technique. Patent pending. For licensing, inquire within and bring money. Lots and lots of money.

Categories
Diversity XHTML/HTML

The women of XML

Dare Obasanjo wrote a terrific post in response to my noticing that the Applied XML Conference had no women speakers. He listed out several women in the XML world who would be great speakers, several of whom I was familiar and agree with him, 100%.

In particular, I would be intrigued by a presentation by Lanqing Dai, who is now working with WinFS, but used to work with the XmlDocument class. The subject of WinFS came up in conversation in a thread associated with a post I wrote over at Practical RDF, and I’ve been wanting to learn more about it.

(Yes, time to drop some of my bias about Longhorn and take a closer look at the technologies.)

Another person to add to this list of exceptional XML leaders and practioners would be Dorothea Salo, who recently gave a tutorial on XML classification systems at Extreme Markup, and who was also one of my tech editors for the Practical RDF book.