[uf-discuss] Comments from IBM/Lotus rep about Microformats
Mike Schinkel
mikeschinkel at gmail.com
Thu Dec 7 12:28:40 PST 2006
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.
More information about the microformats-discuss
mailing list