The Pitfalls and Perks of Adopting a New Standard

Monta writes to tell us that IBM DeveloperWorks has an interesting article about the pros and cons of 'adopting a standard before it becomes one'. From the article: "Whether a standard will succeed and be widely adopted is ambiguous at first, regardless of who endorses it -- a major player or a fringe element. So if most people don't like to welcome the new guy, why would they put all their eggs in a standards basket when that basket might not exist tomorrow?"

Comments

Sometimes...

[Stanistani]

Getting a product to market with a new technology can advance the adoption of a standard.

Chicken, meet egg.

Of course it's a gamble...
but that's one way to make the big money.

Re:Sometimes...

[Myu]

Getting a product to market with a new technology can advance the adoption of a standard.

It is, arguably, the only way to advance it. No matter how efficient a standard is at its job, it doesn't become "Standard" until successful implementation.

Good Quote!

[dkf]

"Great minds think alike; hurried developers make similar mistakes."

RS-232

[mark-t]

Many people adopted that "standard" long before it became EIA-232 (now TIA-232, I believe).

Adoption that makes things become standard. Not the other way around. At most, all you do is create a "recommended standard", which is interestingly what the RS stood for in that famous 25-pin bus.

Re:Examples

[Breakfast Pants]

I read the first guy's post and I was like "wow he really has some good points." Then I read your post and I was like, "wow, that first guy was an idiot." It really goes to show how far someone can go with a bunch of stuff put together with no factual basis and a bunch of terms from the topics at hand thrown in. I can't believe I didn't catch several of the things you pointed out about his post on my first reading.

Re:Yeah...

[Fred_A]

I know this was meant as a jest, but we already have one and it works too (or more truthfully, it used to).

It goes like this :

1. Write an Internet-Draft RFC
   
2. Implement (twice) the standard to be and deploy it
   
3. Create a working group and document how your two different implementations work great together
   
4. Write a Draft-Standard RFC
   
5. Write a mail rule to redirect flames to /dev/null
   
6. Reword your Draft Standard and write a Proposed-Standard RFC
   
7. Empty /dev/null which overflows from all the flames that were dumped into it
   
8. ???
   
9. Wait until your Proposed-Standard is upgraded to Internet-Standard status.
   
10. Profit ! (not)
    
    So you won't get rich, but you'll get famous !
    Well, not exactly famous, but lots of people will have heard of you. And they'll hate you. So it's a bit like being rich. Just without the money.
    

Music ID tags (Yea, OT, an On-T reply to parent)

[Keybounce]

It sounds like you are really looking for a relational DB format of ID tagging.

A song can have many authors.
An author can have many names
An author can have many songs
A name can have many authors

You need a many-many for song/artist, for artist/name, for name/artist ("Monkeys", for example, may not mean the same people today as it used to), etc.

In fact, you'll have many/many tables EVERYWHERE in a really complete system, and you're going to want some way to transfer information from one DB to another DB maintaining the same many/many intermediate information as you transfer across DB's ...

> Secondly, it's a waste to have an extra entry just for that one song.

You will wind up having to use a lot of UUID's in pairs for each table entry, and you'll have a lot of those entries. Last time I checked, generating a UUID took 16 bytes, so each line of each many/many table is a 32 byte entry, and each song will trigger many many/many entries.

Were you trying to save space somehow?