Ambiguous Specifications do not make Good Technology

There is a belief that if it weren’t for the fact that the earliest versions of HTML were unstructured–full of proprietary idiosyncrasies and ill-formed markup indulged by too-loose browsers–the web wouldn’t have grown as fast as it did. Somehow, we’ve equated growth with bad and imprecise specifications rather than the more logical assumption that the growth was due to interest in an exciting new medium.

As such, we’ve carried forward into this new era in web development an almost mythical belief in bad specifications. If we wish to have growth, we think to ourselves, we mustn’t hinder the creative spirit of the users by providing overly rigorous specifications. Because of this belief, we’re still battling ill-formed, inaccessible web pages created by a legion of web page designers who picked up some pretty bad habits: namely the use of deprecated attributes and proprietary elements, as well as the use of HTML tables for everything. Well, everything that isn’t covered by the use of non-standard and proprietary Javascript–use of which results in the annoying messages that one needs a specific browser, or worse, a specific operating system in order to see this Wonderful Thing. Go away until you’re properly equipped.

What we’re finding now with web page designers today, whether they’re amateur or professional, is that it’s just as easy to learn how to do things the right way, as the wrong. What’s important is to provide good, clear documentation, as well as good, clean examples. Contrary to some expectations, adherence to standards, and precise specifications have not killed the spirit of creativity.

In the end, rather than aid the growth of the web, bad specifications slowed it down as a new generation of web pages had to be created out of the ashes generating by burning the old.

Learning how to do things right has such rewards, too. It’s knowing that your page looks good in all operating systems and most browsers; that people can easily navigate your site; that there are a hundred new tools and toys you can use now because you’re using precise and structured markup. Being able to validate a page isn’t a matter of dumping a fairly useless sticker into a sidebar; it means being able to drop in a Google map, or add in-place editing, or automatically pull your calendar out of the page, or any number of wonderfully useful and fun innovations.

We still continue with this belief, though, that to standardize or embed precision into a specification is to stifle the creative juices of the consumer of the specification: whether they be developer, designer, or end-user. Why? What can possibly lead anyone to believe that you can create good technology out of a bad specification?

Some would point to RDF and say that this is a case of a very precise specification that has not led to quick adoption. However, it isn’t surprising that there isn’t billions of RDF/XML documents scattered here and there, and it has nothing to do with the precision of the specification. Some folk didn’t, and still don’t, like the look of the externalized syntax of RDF; others felt that semantics should arise from existing elements; and still others just don’t see the need for it, and won’t until you give them an application that demonstrates this directly for them.

Oh, there’s some pieces of the RDF model we might do without, but precision is not one of them. I look at the precision of the specification of RDF with nothing but relief. I know that the work I do now with RDF follows a model that’s been carefully defined, intimately documented, and rigorously tested. I can trust the model, and know that the documents I create with RDF today will parse just as successfully as documents I’ll create five years from now; more importantly, knowing without a doubt it will mix with your data modeled in RDF.

That’s why I look with some confusion at the backlash against efforts to clarify the RSS 2.0 specification. There is no doubt–none whatsoever–that the RSS 2.0 specification, as currently written, is ambiguous; from what we’re hearing now, in comments and email lists, it is being kept deliberately so. I don’t understand this. This would be no different than to ask Microsoft not to follow standardized use of CSS in the new IE 7.x. Why on earth would anyone want this?

I am just a simple woman who works in technology. Perhaps one of you can explain it to me in such a way that I can understand.

I wrote on the ambiguity in RSS 2.0 as regards to enclosures here, and actually had to modify Molly Holzschlag’s weblog software (WordPress) because her posts with enclosures would cause tools such as Bloglines to break. These are two very popular tools; hence, the ambiguity in RSS 2.0 specification does cause problems. This is a proven fact that no amount of marketing and cheerleading can obfuscate.

Throw as much money as you want at it; write the most glowing reviews; get prestigious names to exult its beauty and power; seek to crush a non-existent enemy if you must–it is still not ‘good technology’. It may have damn good marketing, and lots of dough invested in it, and even have widespread use–but it is not good technology.

I am puzzled as to how anyone, particularly those who work in technology, could say otherwise. I await enlightenment.

This entry was posted in Technology. Bookmark the permalink.

22 Responses to Ambiguous Specifications do not make Good Technology

  1. I keep saying: MONEY – $100 million venture capital fund.

    Try it out loud: One hund-red milly-yon dull-ars. That’s a lot of money (it’s not clear if it’s actually $100 million, but that was the target). And such an amount of money has its own imperatives.

    As I wrote in my post: The RSS Circus Is In Town, or, Specification As A Money-Ball – “we’re not in Kansas, err, geekland anymore. We’re in Oz, err, business”.

    “my assessment is: The Money Rules. It’s clear that The Money is nervous. There’s activity by Microsoft, and other big corporations. Any hint that there might be anything which casts doubt on the stability, primacy, readiness, usability, etc, of the great big asset they are trying to leverage, frightens The Money. It Will Not Be Allowed.”

    [Edit - Before the Big Dog gets mad at me, I should clarify I don't think he's personally motivated by the money - but I do think the environment created by the money creates a situational madness]

  2. jeneane says:

    he’s not personally motivated by money? have you gone stark raving mad too?

  3. Shelley says:

    Seth, I agree that Harvard’s motivation is not based on altruism. I also agree this is not what’s motivating Big Dog.

    I also know this is a subject that people have heard too much about, primarily because we’ve heard it all before, and because of the personalities involved. But after watching people being intimidated into silence the last few days, well, just didn’t want to let it slide.

    People just don’t care, though. They just don’t care.

    update Hey Jeneane. You and I must have commented at the same time.

  4. People just don’t care, though. They just don’t care.

    I’ve tried to care this time around but mustering enough energy to give a shit hoot about yet another RSS flamewar seems to have been beyond my capabilities.

  5. jeneane: Not on the level of the VC’s. That’s a totally different mindset. Those guys *will* do whatever it takes to get their cash-out, not a matter of it’d be nice to make a few bucks. It’s the difference between money and The Money. Unfortunately I really can’t write my full analysis, heck, I *am* intimidated into silence (I’m way below the VC’s radar, but not an A-lister’s).

    Though I think people are missing that it’s different this time. Way different. Because of that investment fund money being very directly involved. Right now an implentation VC guy seems to be conferring with a Harvard VC guy, and reading between the lines, I believe there’s some fear the two VC’s will cut a deal, and who knows what that might be? (and the meaning of “big fish in a small pond” of the blog world is never more apparent).

    Obviously this is still inside baseball. But let’s say it’s quite another lesson besides the tech design debates.

  6. Scott Reynen says:

    “This would be no different than to ask Microsoft not to follow standardized use of CSS in the new IE 7.x”

    Some web designers are actually doing that, so they don’t have to adjust their own CSS hacks to work with a standards-compliant IE. Some people prefer broken to change.

  7. Update : Harvard Lawyer/VC seeks to re-assure Big Dog, won’t be backstabbed (completely expected, but I wouldn’t have faulted worry about it – anything can happen). Saber displayed, though ceremonially, not yet rattled. Deal-cutting efforts continue.

    Developing :-) … Stay tuned …

  8. Seth Russell says:

    … we’re still battling ill-formed, inaccessible web pages created by a legion of web page designers who picked up some pretty bad habits: … Well, everything that isn’t covered by the use of non-standard and proprietary Javascript

    What do you think about Drag&Drop ?

  9. Chris Lott says:

    I don’t find myself agreeing with you (Shelley) very often, but in this case you are spot-on. There are things that are obviously broken with real-world ramifications– it would hurt nothing to fix them. Why in the world would anyone object? I don’t think it’s about money… I think it’s about ego (surprise, surprise).

  10. Danny says:

    What you said, Shelley. Castles made of sand…

  11. Chris, I mistrust “ego” as an explanation – it’s too easy to make it name-calling, too simple because it works for anything – “Personal!” “Ego!” “Drama!” – if it can be hauled out for everything, it explains nothing.

    If this were just a matter of what some geek wanted, the VC’s would do a deal cutting him out, in a New York minute. The fact that that hasn’t happened tells you there’s monetary reasons backing both positions.

    It wouldn’t hurt anything technical to fix the broken things, quite the opposite. But it could hurt the business marketing to admit any change is needed, even the most minor clarification – that is why the word “revision” cannot be tolerated.

  12. For better or worse, 100% of my knowledge of the history of RDF comes from reading the opening chapters of your book (Shelley), Practical RDF. One thing that surprises me, or perhaps just makes me curious, is the lack of dominating personalties in that history. You mention Ora Lassila, Ralph Swick, Dan Brickley and R. V. Guha by name, but after that most of the action seems to happen in the RDF’s Core Working Group. As you tell this history, there is no single, dominating character or corporation, as there is with RSS.

    You clearly feel that RDF has less ambigiousness than RSS. Why do you suppose that came about it? Do you feel the lack of dominating personalities and corporations allowed RDF to develop a better, more helpful, process for dealing with issues as they arose? Are the politics/processes of RDF simply less corrupted than what we’ve seen with RSS?

  13. McD says:

    I’ve spent way too much time obsessing with trying to understand the politics and dynamics of the RSS.

    Is it the money, the ego’s, the tension between the “revolutionary vs the evolutionary”? Probably not.

    I can see that Dave Winer has no patience for the esoteric details of standards work. His post today asking the average scripting news reader if they understand a point Sam Ruby is making in an email to the RSS-Public working group indicates Dave’s frustration with excessive nit picking over details.
    It makes him crazy…

    At some point Dave just took his work and shut down any possiblility of anyone changing it. That’s what the Harvard deal is… an RSS Timevault. Locked. Now it’s time to move on to OPML. Will there be an OPML 1.1 Spec? Why bother. Let the coders reverse engineer from Dave’s OPML Editor.

    Then Rogers Cadenhead took the opportunity to consider some small clarifications on the most pressing RSS 2.0 ambiguities. He invited some RSS interested folks to join the RSS board and Atomites Sam Ruby and James M Snell showed up on the RSS-Public email lists to see if Rogers was truly serious about cleaning up anything ambigious. They were ready to work the issues… they were born to work such issues.

    Well, Dave went ballistic and after a vote was requested on the can an “item have more than one enclosure” issue… (most think it’s a bad idea) but Dave saw the slippery slope: let them make one “clarification” and we soo won’t recognize the Spec from my work… so, just stop. It’s frozen. Sam must go work another standard’s patch.

    Start a “molecule” standard, Dave suggested. See if it has some chemistry but leave my work alone.

    Dave got 2 of the Board members to resign due to a potential for conflict over RSS becoming a football for corporate advantage. Another concern that keeps him blogging at all hours.

    It’s too bad that they can’t just nail down the “best practices” around the fruzzy areas but there’s that damned slope.

    The lack of clarity around some issues will open the door for MS and Apple to just do almost anything they want with RSS and make the little guys even more crazy about the effort to make it ALL play well in their software. But Dave’s ready to turn the hoarde against them if they try.

    The only spec that’s more confused might be Calendaring Syncing. I’m sure Dave will make his calendar work over RSS 2.0 using OPML in an enclosure and the world will be able to sync up on appointments… you just won’t be able to know what time standard to use. But it’s a start.

    At Sun they used to call a program “Bill Joy Ready” when the code passed a “lint” test… With Dave it’s
    “Winer Ready” when the OPML Editor can read or write it. That’s a personal standard of excellence for a career coder: “I got it to work… for me.”

    The rest of you… “get to work”.

  14. Shelley says:

    Lawrence, RDF is a model defined by a group of W3C folks from all over the world. I can’t even begin to tell you the number of scary smart people who helped contribute and test this model. However, none of the folks are really heavily into marketing–most don’t even insist their names be attached to the work. They just want to see it succeed.

    RSS is bits and pieces pulled from three or so standards, ruthlessly marketed by a man with more energy than XML skills.

    McD, I don’t know what started the recent whatever. I am intrigued by how quietly it’s been received. This must concern a few folk with much at stake.

  15. [RDF] I can’t even begin to tell you the number of scary smart people who helped contribute and test this model…. RSS is bits and pieces pulled from three or so standards, ruthlessly marketed by a man with more energy than XML skills.

    Right, ok. So RDF has benefited from a better process. RSS has been corrupted by bad politics, too much money, and the flaws of the central character who has pushed it forward. I do get that. But I’m left confused, then, as to why Atom hasn’t made more headway. Even support from Google hasn’t given it take-off speed. If it’s less ambigous then it offers a better platform for future develppment. So why would a company like Apple stake itself to RSS 2.0? I’m confused. What does Atom need to break through to the kind of mass uptake that RSS has seen?

  16. Shelley says:

    What does Atom need?

    Atom needs more exclamation points: Atom!

    Atom needs more Web 2.0: Atom 2.0 beta!

    Atom needs VC funding: Atom 2.0 beta! received 12 million in first round funding.

    Atom needs a list: Top 100 webloggers using Atom 2.0 beta!

    Atom needs more social software goodness: Find and make friends using Atom 2.0 beta!

    Atom needs more aggressive, even ruthless marketing: Atom 2.0 beta! will replace J2EE AND .NET and bring about world peace.

    Atom needs supporters in high places: Steve Gillmore, writing on Atom…Adam Curry digs the name…

    Atom needs a leader who will stop at nothing to promote his or her ownership of Atom: (sorry, can’t seem to find one)

    Atom needs more controversy: “Sam Ruby tells Mark Pilgrim he can’t play on the Atom 2.0 beta! team any more!”

    Atom needs to be called ‘RSS’ — because that’s all that matters, the name. So…Atom RSS 2.0 beta!

    Atom does not need to be a well-thought out, tested, and highly documented specification turned over to a neutral standards body, which, unfortunately, is what it is.

  17. Can I fork Atom? I can’t fork RSS. Perhaps I should just fork myself.

  18. dave rogers says:

    To quote The Blue Raja (Master of Silverware), What the fork, let’s do it!

  19. dave rogers says:

    To add to Shelley’s list of Atomic needs, Atom needs an awards series to “honor” high attention-earning webloggers.

    They could be denoted by a periodic table, laid out in CSS of course.

    Maybe there should be a Top 118, with their ranking determined, I don’t know, by their Atomic Number (not to be confused with that other number from Mark Pilgrim, though perhaps that could be a factor in determining the Atomic number.)

    It needs some post-Cluetrain marketing. Perhaps they could assemble and “advisory board” of highly regarded, non-controversial figures who espouse popular beliefs that have no motive force apart from generating good feelings (And what’s wrong with good feelings, anyway?) to direct some more attention to it.

    It definitely needs more cowbell.

  20. Can I put in a note for the mythical merged format, the

    “Atom / RSS Syndication Enabler” == ARSE

    As in, “ARSE feeds”.

    Need I belabor the utter obvious utility it has (not to mention accuracy :-)), in terms of describing to newcomers what it does?

    (Inspired by AndrewOrlowski -

  21. Shelley says:

    ARSE works for me.

  22. Chris Lott says:

    Well it doesn’t give one much hope that OPML will turn out any better than RSS… assuming that Dave will arbitrarily freeze its development as well. Of course if DAVE is blindsided by something that actually effects DAVE, then all bets are off. He’s certainly be behind fixing it, just as he was behind fixing the HTML Encoding issue.