[uf-discuss] Principles of Microformats?

[Mike Schinkel]

Thanks for taking the time to review; it was very helpful.  I've answered
your questions and/or clarified my comments.

Benjamin West wrote:
> > 2.) One flat namespace
> Not sure what this means.  There is one "namespace" for class 
> names, yet the markup itself is hierarchical.

That's what I meant.

> > 3.) No solution for resolving ambiguities
> Not sure about this.  The mailing list, IRC, and the wiki 
> serve as venues to build consensus in the face of ambiguities.

No technical solution build into the markup.

> > 4.) No Microformat registry
> What would a registry look like?  We have XMDP and the wiki.

Like the list of RFCs.  And like the list of W3C's specs.

> > 5.) No versioning capability
> Someone recently brought up versioning.  It will be 
> interesting to see where that goes.  What is the use case for 
> versioning?

Something is added to the spec, or it's changed; How can a parser tell which
"version" the markup writer was using?

> > 6.) Recognition is exclusive
> Yes, a microformat exclusively refers to the product of the 
> microformats process.  I honestly don't know why other usage 
> has cropped up.

See earlier explainations by Joe Andrieu, S. Sriram, and Håkon Wium Lie.

> 
> > 7.) Requires community process and approval
> One of the key ingredients in a microformat is wide and 
> pervasive represenations of the data being considered on the 
> web already. > Without this, microformateers are likely to consider a 
> representation esoteric.  I'm not sure what community you 
> mean here, and I'm not sure it's *required*, but OTOH I don't 
> know how you can create a microformat without the help of the 
> community: at least to the extent that many people are 
> already trying to publish the data being considered.

The community is this mailing list, and Tantek recently wrote several times
that it wasn't a microformat unless it went through the community process.

> > 8.) Envisions limited scope
> With regard to what? The problem-space is typically well 
> defined.  Use cases help us define what we are doing.  OTOH, 
> we see wide adoption of microformats as well as applications 
> to use cases we had not considered.

Non-visible data.  Only considers existing market, not potential markup.
Community process not interested in scaling. I could add more.

> > 9.) Process favors expedience
> Compared to what?

Multi-year processes that require HTML to change, for example.

> > 12.) Centralized control and approval authority
> Controlling what? Authority of what?  Some resources are 
> secured by a few for the health of the community, eg the 
> mailing list, the wiki, the domain name...

Control of what gets considered a microformat.

> > 14.) No delegation of decision authority
> Decisions are spread throughout the community.  Does this 
> conflict with 12 or is the authority over something different?

For example, no ability to create a "wine" microformat and split off it's
own mailing list and working group where those not interested in wine don't
have to participate, and those only interested in wine don't have to
participate in the "art" microformat.

> > 15.) Implementations not part of process
> I'm not sure what this means.  Plenty of people implement 
> stuff, seemingly through the phases of the process.  In fact, 
> I imagine it would be possible to design a microformat from 
> pre-existing implementations and formats they operate on.

Creating client parsing implementations for major platforms is not a
required part of the process.

> > 16.) No officially recognized implementations
> What would an officially recognized implementation look like? 
>  We have many community implementations.  Aren't those official?

Duplication of "No Microformat registry", sorry.
 
> > 17.) Inspired by needs of Bloggers and blog-related services
> Use cases involving bloggers are easy to come up with, 
> however I started working on microformats before I had a 
> blog!  Anyway, I suspect blogger-based use cases are good 
> because they are so user-centric.  It is certainly not the 
> focus of microformats, I think.

However, a blogging aggregator/search engine is funding time spent my the
leads of the process, so there will inevitably be subtle biased towards
bloggers, even if they try not to because those are the use cases they
identify as having value. For example, use-cases which enable e-commerce
companies to exchange data with their vendors and suppliers is not on their
radar.

> > 18.) Emphasizes general purpose needs
> How does this compare with number 8?

I'm referring to the fact that the process is designed to be broadly usable,
not for addressing vertical needs. Looking at the list of "specifications"
and "drafts", all are blog related or general purpose.  Looking at the
"exploratory discussions", the vast majority are general purpose. 

As a counter-example, assume that you opened the New York City yellow pages
and listed off every section. For each section, there's a potential vertical
format. The current process cannot handle that level of specificity, and
when I've proposed changing I've been told that that was not the vision for
microformats.

> > 20.) Aims to avoid changing publishing behavior
> I'd say we aim to codify publishing behavior in a way that 
> minimizes the need to change where possible.  For example, 
> IIRC, all semantic lists are valid XOXO.

Quoting from Tantek "...microformats do not try to alter people's publishing
behavior in an unnatural way..."

> > 22.) Constrained to enhancing known use-cases.
> I've recently come to believe that working without a use case 
> is silly.

Let me rephrase that. "Constrained to enhancing use-cases currently
published on the web" (as opposed to use-cases for data planned to be
published on the web.)

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/