Roger L. Costello wrote: >> Mike, you've raised some excellent concerns. It fundamentally boils down to an issue of interoperability. If the Microformat's community splinters and, say, multiple versions of hCard are created then we immediately have an interoperability problem.
I believe that what appears to be the vision for Microformats among the group based on the majority of replies that either appear to be authoritative or were definitely authoritative will end up frustrating people who originally were enthused by the concept and cause them to go off and create their own markup that is potentially incompatible and chaos will ensue. >> Tantek calls namespaces an enabler of stovepipes. I agree that XML namespaces are a nightmare. But I think a much simpler mechanism can achieve the same goal. But rather than just complain and say there is a problem, I will instead propose a simple solution. 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. Respectfully, -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ P.S. I came to Microformats thinking the above was logically be how it would have been implemented, but I quickly become disillusioned after learning how there was not vision associated with seeing it scale to meet the needs of the entire internet community. I now feel that without reform the best Microformats can ultimately achieve is not be too terribly damaging. I hope that others can come to see my logic. _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss