[whatwg] microformats incompatible with WebApps 1.0 ?

Mike Schinkel mikeschinkel at gmail.com
Mon Dec 11 21:55:20 PST 2006


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/







More information about the whatwg mailing list