Fussing about formats, Micro or otherwise

August 25, 2005 - 2:26pm — bmann

OK, Peter Caputa, you pushed me over the edge with this one:

Exactly. Microformats could be as big an innovation as databases were.

If databases let us store information. Microformats let us access the world's databases. Potentially!

Yes, APIs do this too. But, microformats make the database (or data store) distributed. Not controlled by one entity.

pc4media: MicroFormats Enable Distributed Applications!

Umm. OK. Except....all the microformats that are going to be in wide usage are going to be auto-generated by dynamic systems of some kind (e.g. WordPress, Drupal). Which run on databases. Which can just as easily use an API directly or generate a standard format (e.g. vCard, vCal, etc.) that *works today*.

I'm not against microformats. Chris and I had a long discussion in Portland about this, wherein I couldn't make my point clearly. The usefulness that I have seen is some Greasemonkey scripts that take hCard and hCal and automatically create....vCard and vCal.

For the time being, these standard formats are well understand by lots of applications. Double-click them, and your local OS will "do stuff".

I think Chris' point is that eventually, the browser will be able to understand all of these things natively, while parsing. Well, except, I don't want my browser to be one big bloated app that does everything. We've been there before, and it sucks. See also: Firefox, Thuderbird, Sunbird, etc.

For now, I'm sitting microformats out. We'll happily support them and generate them (and yes, having a common layout from a design perspective is useful), it's just that it's easier to build distributed apps today by using APIs. Which are distributed.

Please bang me about the head if there is something I'm missing here.

Comments

August 28, 2005 - 11:36am — bmann

Micro-blargh

No, Peter, I did *not* say that "no-one has done anything useful with microformats" (Peter's words) -- the point I continue to try and make is that currently, microformats are a solution in search of a problem. APIs and existing standard formats seem to work today. Less with the pot stirring, more with the explaining.

August 27, 2005 - 11:51am — Tantek (not verified)

microformat implementations

Hi Boris,

Great to hear that you will be supporting and generating microformats. Please let me know how I can help.

And just to let you know, there are tons of microformats implementations being developed.

Take a look at the microformats implementations page for starters -- implementations are coming out so quickly that it is difficult to keep that page up to date!

As far as generating hCard, hCalendar vs. generating vCard, iCalendar, we have found it is a) much easier to generate hCard and hCalendar, and b) people are already publishing contact information and event information in free form visible text on their web pages, and they are much more amenable to adding a tiny bit of markup to what they are already doing, rather than being asked to learn a new format and export another file. And that's not just for authors, but for developers as well. Developers like things being easier as well.

In addition, hCard and hCalendar allow you to both embed them in the context of other content (which a separate file does not), and nest even more detailed structured information inside of them (e.g. an hCard for the location of an hCalendar event, or rel-tags for categories, both of which EVDB is already publishing on tens of thousands of events).

Tantek

August 28, 2005 - 1:49am — bmann

people are already publishi

people are already publishing contact information and event information in free form visible text on their web pages, and they are much more amenable to adding a tiny bit of markup to what they are already doing, rather than being asked to learn a new format and export another file

You're thinking like someone that hand-codes pages. I'm thinking that the vast majority of such data will be auto-generated by various CMS/blogging tools (as I stated), for which it is not significantly harder to generate existing formats that are supported today. "People" will not be learning markup nor exporting to another file at all.

The nested structure part is the only thing that I find interesting so far.

August 28, 2005 - 2:45pm — Tantek (not verified)

even CMS/blogging tools have templates - which are hand coded

I'm thinking that the vast majority of such data will be auto-generated by various CMS/blogging tools (as I stated),

Yes. And those CMS/blogging tools have templates themselves for generating their pages, and those templates are handcoded, typically by web designers, for whom supporting microformats like hCard and hCalendar are easier, again, because they don't have to learn new languages/file formats. It's also much easier to modify templates that already exist with a bit more markup, than it is to create new templates to export new file types in new locations etc.

... for which it is not significantly harder to generate existing formats that are supported today.

Even if it is a little harder, people (the web designers that author those templates) will choose the easier solution, or in some cases, having an easier solution will make the difference between whether they do it or not. Plus, why waste time with something that is harder (new templates, additional file formats and files) when there is no advantage to it?

"People" will not be learning markup nor exporting to another file at all.

The people building the templates, modern web designers, already understand semantic XHTML, and using meaningful class names. If anything, by providing a default set of such meaningful classnames to use, microformats makes their job easier.

Tantek

August 25, 2005 - 4:08pm — Peter Caputa (not verified)