[microformats-discuss] Discovery of microformats

[Ryan King]

On Jul 12, 2005, at 2:12 PM, Joshua Porter wrote:
> Is it fair to say that microformats are no further along in auto- 
> discovery than are standalone XML formats?

I still don't understand what you mean by "auto-discovery." Can you  
explain a specific case that you're imagining?

We need to ground this discussion in a real use case.

> I ask because I'm confused about the "support" of microformats. I  
> understand that microformats are "supported" by browsers in the  
> sense that browsers read them as XHTML. But that's not really doing  
> anything with the semantics we've added to our markup.

Right. Browsers aren't *currently* doing anything special with them.  
But there is certainly room for user stylesheets and scripts (like  
Greaemonkey) to begin taking advantage of them immediately.

> (we might as well be writing in any arbitrary format).

Actually, no. On of the goals of microformats is to add structure to  
data which is already being published. hCalendar has some great  
examples. The Squid List <http://laughingsquid.com/squidlist/>, for  
example, was already publishing events and it was trivial for them to  
add hCalendar markup to that page. There's no reason for the laughing  
squid guys to publish a second representation of their data when one  
will suffice (and is going to be published no matter what).

> Taken further, it seems to me that for anything to be done with  
> microformats, our UAs will need to be updated in some fashion.

Right. But, of course, in the meantime, they're not breaking anything  
and you can still view the data in a browser.

> Of course, Technorati is supporting some of them already....but we  
> don't want something that will be supported by only one  
> vendor...and presumably Technorati would support another XML  
> format, too.

Technorati is not the only organization supporting microformats. And,  
Technorati suppports other XML formats.

> Thus, microformats, to me, sound like just as much work as would be  
> a separate format (like RSS).

I understand how microformats can seem like a lot of work- we're  
adding all sorts of markup and constraints. I think, though, that in  
most cases you've already done most of the hard work to produce html  
documents and adding microformats will be relatively trivial.

An example would be upcoming.org. They implemented hCalendar in  
*under an hour.*

> Indeed, many of the microformats are based on living formats  
> written in plaintext or xml. So some are already developed...like  
> iCal, xCal, and OPML.
>
> Therefore, I wonder if there are some applications for which a  
> separate format are better suited, and presumably some applications  
> for which microformats are better suited.  Does anybody have a take  
> on this?

Yes. Remember, microformats are intentionally limited in scope. There  
are many problems which are unsuitable to microformats (like making  
coffee :)).

> However, I'm hearing this push about microformats...which is all  
> well and good...but I don't know, as a developer, where I should  
> *spend my time*.

Take a look at the things you're already doing- data you're already  
publishing and see if any of it could benefit from being published in  
a more structured manner.

> A possible issue to address would be: should I provide OPML or XOXO?

We can't answer that question for you- you're going to have to do so  
based on the constraints of your own project. I, personally, would  
encourage XOXO use, for many reasons... but that's a topic for  
another thread.

Josh- thank you for your interest in microformats and thanks for  
taking the time to be engaged in the community. I just hope that my  
comments here are helpful.

-ryan