[uf-discuss] Principles of Microformats?

[Benjamin West]

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