[uf-discuss] Live Writer and microformats

Fri Oct 6 11:07:03 PDT 2006

On Oct 6, 2006, at 1:19 AM, Joe Andrieu wrote:
> Because of the current structure of microformats, as a way of  
> thinking and as a process, I believe it is inherently incapable of  
> handling a rapidly growing list of microformats.
>
> Someone once said to a proposal of mine that a large number of  
> microformats was in fact an "anti-goal".  The way the system is set  
> up, neither the supporting technologies nor the uF community is  
> capable of handling a rapidly growing set of uF.
>
> We have a very slow, painstaking process,

Have you tried any other standards processes?

According to a talk [1] given by Tim Bray (see notes [2]), the atom  
syndication format took over 17,000 email messages to work out.

And you know what? It's not done, its still in draft (or maybe  
proposed). They have at least one more round before finishing.

On the other hand, I see 6,277 total messages in the history of this  
mailing list. In that time we've done hAtom, hResume, adr, geo, rel- 
directory, hListing and talked about a number of other examples.

It may not seem it, but this is the fast way to do data format  
standards.

Consensus takes time. Community takes time.

> Second, because there is no mechanism for discovery of  
> microformats, every
> tool has to be hand-carved to handle each microformat it wants to  
> support.
> In contrast, if we required profiles, and if profiles provided a  
> machine
> readable schema of the microformat, tools could at least present  
> users with
> structured data that at least retains its typed values.  Of course,  
> the
> /semantic/ value of that auto-discovered microformat is more  
> challenging; we
> don't have a good way to define arbitrary semantics.  But at least  
> the data
> can be extracted and managed in a lossless fashion. Plus, if the  
> format
> contains well-understood components such as hCard or hEvent, at  
> least the
> application could provide reasonable interfaces and functionality  
> for those.

The idea of auto-magically making microformats work is a dream. I'll  
believe it when I see it. For a hint at some of the challenges, read  
http://microformats.org/wiki/hcard-parsing .

Parsing, extracting or using microformats is not intended to be easy  
for consumers. Remember, we're optimizing for publishers, which means  
that we'll often create situations that put a burden on consumers.  
However, there's more producers than consumers, so the economics here  
are good.

Also, we could try to require profiles, but I don't think it'd make  
any difference. The reality is that a lot of content on the web is  
published with systems that don't allow authors to edit the <head />  
of the document.

If we were to require them, I could see two outcomes:

1. Only a minority of people use them. Consumers will have to deal  
with it the same we deal with it today.

2. The publishing tools start putting all of the profile URIs in the  
head at profile, just in case their users publish microformatted content  
through their CMS.

I don't see either of those scenarios being helpful for us.

> So, I think it is important to realize that the fundamental  
> structure of uF
> as a process, organization, and way of thinking, inherently  
> restricts the
> pace of growth.  uF is set up to slowly forge several dozens of uF,  
> crafting
> socially accepted, shared semantics and encoding standards for use in
> semantic XHTML.  Good stuff. And far more accessible and useful  
> than most of
> the other semantic web technologies out there.

The structure of the process and community is built to produce good  
results. Good results take time and work. Still, as I mentioned  
above, I think we're able to produce good results in less time with  
less work.

> With all that said, maybe I'm looking at things upside down.  I  
> asked Tantek
> early on how microformats scaled.  His reply was that could be better
> answered over a beer.  Unfortunately, I haven't made it to any of  
> the social
> functions to chat over that beer, so maybe I could get some  
> clarification
> here.
>
> I'm I missing something?  Or is the scaling of uF, in terms of the  
> # of uF,
> constrained as I've outlined here?

The growth is constrained to the formats we can successfully create.  
Quality is better than speed.

> At the same time, organizational development is a wicked hard  
> problem and
> one we should be very delicate in approaching, if approaching it at  
> all.

Perhaps even harder than writing software or developing data format  
standards. :D

-ryan

1. http://www.tbray.org/talks/etech2006
2. http://www.windley.com/archives/2006/03/tim_bray_on_ato.shtml