Mike, interesting list.
1.) Includes visible-only
Yeah, microformats only represent visible data.
2.) One flat namespace
Not sure what this means. There is one "namespace" for class names, yet the markup itself is hierarchical.
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.
4.) No Microformat registry
What would a registry look like? We have XMDP and the wiki.
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?
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.
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.
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.
9.) Process favors expedience
Compared to what?
10.) Specifications allowed to evolved w/o explicit finalization
11.) Considers existing HTML usage
If a particular type of data isn't already being representing in HTML, we typically avoid developing a format for it. Also, we use the same techniques many authors use, such as using class and semantic HTML.
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...
13.) One design discussion mailing list
Dunno about this; what's the status of the mailing list proposal?
14.) No delegation of decision authority
Decisions are spread throughout the community. Does this conflict with 12 or is the authority over something different?
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.
16.) No officially recognized implementations
What would an officially recognized implementation look like? We have many community implementations. Aren't those official?
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.
18.) Emphasizes general purpose needs
How does this compare with number 8?
19.) Focuses on existing content publishing models
Agreed.
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.
21.) Envisions exposing existing content semantically
22.) Constrained to enhancing known use-cases.
I've recently come to believe that working without a use case is silly. Ben _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
