[whatwg] microformats incompatible with WebApps 1.0 ?

[Mike Schinkel]

Here is the proposal I made on the Microformat list just before this thread
started (I omitted my preceding commentary from that email): 

What's needed is a single and "officially recognized" clearing house for
anything metadata tagged to HTML attributes.  Since the WHATWG already
points to Microformats (in the generic sense) as the solution for HTML
extensibility, I believe Microformats.org could easily be viewed as that
central authority.  Without a clearinghouse that is structured to allowing
scale-up, we will ultimately see the use of tags on classes fall into chaos
and it will be far worse than the "serving XHTML as text/html" problem that
exists on the web today.  

Here are the steps I propose:

-- Microformats.org should become a clearing house for "official"
microformats using the structure below.
-- There would be three classes of Microformats: horizontal and
vertical/specific, and vendor.
-- Proposals for a class of "Vertical/specific" Microformats would be
reviewed by a committee and if approved be given a "context prefix," i.e.
"ubio-", "wine-", etc.
	-- Proposals would only be turned down if there is already another
Microformat that does the same thing and can achieve the goals needed of the
proposers
-- Vendors could request and receive a "context prefix," i.e. "ibm-",
"goog-", "ms-", "yahoo-", "ebay-", etc.
-- "Horizontal" Microformats would still be created as today, but ideally
with a "uf-" prefix.
-- All these prefixes would be set up in a managed and machine readable
repository by Microformats.org (or IANA, if applicable.)
-- Create an online forums for discussion of each "Vertical/specific" and
"vendor" context prefix.
-- For each "Vertical/specific" Microformat, there would need to have one
member from the general Microformat community to oversee it to ensure
semantic/syntactic integrity.
-- Multi-element microformats would need the prefix, but enclosed elements
would not (see [1] below) except (see next item)
	-- Exceptions would be when two conflicting Microformats were used
on the same data, then there would be a need to prefix all elements (see [2]
below)
-- Relax the draconian "visible only" aspect of Microformats to keep people
from splintering off who need non-visible metadata.

[1]	<div class="uf-card">
		<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
		<div class="org">Technorati</div>
	</div>

[2]	<div class="uf-card blogsearch-person">
		<a class="uf-card-url fn blogsearch-person-url name"
href="http://tantek.com/">Tantek Çelik</a>
		<div class="org company">Technorati</div>
	</div>

The above is required because of Microformats use of a scarce resource,
similar to how the DNS service is needed to ensure that there is only one
website representing the domain microformats.org. If the above (or something
else that also addresses the issues) was agreed and adopted, Microformats
would become a powerful force of good structured data on the Internet. If
not, Microformats and similar competing efforts will end up causing far less
value on the Internet than chaos, and will eventually be dropped by web
publishers.

BTW, I also would like to see the profile attribute.

-Mike