- From: Mike Schinkel <mikeschinkel@gmail.com>
- Date: Tue, 12 Dec 2006 00:55:20 -0500
Ian Hickson wrote: > You *are* aware of vCard, you can design your metadata > structure with it in mind. If you are worried about clashes, > then stick a prefix on your class names. Less optimally than if I can do it in my own "context/namespace." > I honestly don't expect people to use both vCard and your > format. *I* want to use vcard AND my format (for my website.) So I've just turned your expectation false. > They'll use whichever one does what they need it to > do (typically the most popular one), and ignore the others. That indicates to me you are not operating in the real world where formats are often dicated by external business factors. If two companies each say "markup using *our* preferred format" and those markups conflict, one has to choose. > In the market place, out in the "real world", conflicts will > be resolved by either the languages changing to adapt to each > other, or by some of them being made obsolete and irrelevant > by other more successful ones. That is an idealistic view which is plain false because you can get two entities that are each large and powerful each specifying a conflicting microformat yet there are not in the same industry so they don't see the conflict. However, the few small companies that work with both companies don't have enough influence with either company to get them to change, so they get screwed (all because Ian' thinks this isn't a real world problem.) Maybe the problem is you work for Google, who can dictate, and not for small companies that get dictated too, so you don't see the problem. > Anyway, as it stands, we *do* have a single clearing house > (the Wiki, as defined by the spec). So if you want a clearing > house, that's already taken care of. Wow. I thought I was told a link to a wiki has no business being in a spec....? (If it is, that's good.) > There's no perceived value here. If they call their class > "foo-name" it's for charaters more than "name", and > they are otherwise identical as far as they can see. > It doesn't matter how much real benefit there might be. But you are assuming there is a downside to them for calling it "foo-name" vs. just "name." There isn't; developers use conventions all the time. And if you read my proposal clearly, the prefix is only needed on a top-level element or to disambiguate. Further, here's a real-world example. The company I used to run was a reseller for .NET components. I would have loved to have been able to tell my vendors if they would mark up their product pages with "devtool-xxxx" then my BOT would suck their information down and we could be automatically notified of new products (we often found out about new products from customers which was embarrassing and cost us a significant amount of lost sale opportunity.) > For example, there is a definite advantage to writing pages that are > syntactically correct. Yet more than 90% of pages aren't > syntactically > correct. Why? There's no perceived value in syntactic > correctness, and it > requires more thought. Believe me, I'm keenly aware of the need to motivate people to implement things, and that's one of the first things I think about when I make a proposal. I think "Will they actually implement it?" because if they won't, what good is it? I grew a business from $0/year to $12 million/year from 94 to 99 because I think that way. Respectfully speaking, you just make assumptions that I'm not thinking that way because, in my experience from selling to developers for 19 years, most developers don't think about adoption. I do, a lot more about adoption than I think about technical issues. See my favorite book on the subject, "New Rules for the New Economy": http://astore.amazon.com/mikeschinkels-20/detail/014028060X/103-3893332-2672 604 > It's out of scope for the specification. Ahem. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/
Received on Monday, 11 December 2006 21:55:20 UTC