[microformats-discuss] microformats vs. other formats

[Tantek Ç elik]

On 7/12/05 2:54 PM, "Danny Ayers" <danny.ayers at gmail.com> wrote:

> On 7/12/05, Joshua Porter <porter at bokardo.com> wrote:
> 
>> 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?
> 
> I was originally very skeptical of the whole notion of microformats -
> I mean, what do you need XFN (embedded) for when you've got FOAF
> (linked)?

Poor example because they capture different information
<http://gmpg.org/xfn/and/foaf>, but the point of (embedded = mark up of the
visible content already being authored) vs.
(linked = create a whole new separate file, in a new language), is a very
good point.

(BTW, a better comparison might be hCard vs. FOAF, since FOAF itself is more
about contact/profile information and has no more to do with social network
relationships than plain blogrolls).


> But they've grown on me, and I do think there's a range of
> applications for which they do make a lot of sense. As a rough
> characterisation I'd guess:
> 
> * persistent
> - because there are loads of things that you might e.g. want to put in
> an RSS feed that you wouldn't necessarily want to hold onto forever on
> a HTML page.

Excellent point Danny.


> * having both human-readable (doc) and machine-readable (data)
> components, with significant overlap
> - I'd look for the overlap, because if you can avoid repeating
> yourself that's usually a good thing.

Another very good point.  A lot of folks seem to underestimate the hazards
and problems of duplicating data in multiple places in a publishing system.

Heck, at Technorati we see LOTS of problems and inconsistencies between
blogs and their RSS feeds.


> A lot of the time you could
> generate both a human-readable and a machine readable representation
> from the same source, e.g. a database producing a blog in HTML and
> RSS. I'm not sure, but where there's more metadata than content it's
> probably better separate, and vice versa (i.e.  in retrospect Really
> Simple Syndication might have been simpler done completely as HTML).

Indeed.  If it were 6+ years ago and we had come up with the vision of
microformats, we could have introduced a syndication "microformat" that
would have been *much* easier to develop for than RSS, and thus would have
outpaced its adoption.

With RSS, we are simply too late.  There is some chance that Atom will do a
better job, but from a microformat perspective, they're both new XML
formats.


> * when it's easier that way
> - a tricky one to judge - I think hReview works very well as a
> microformat (even though I've personally done an RDF/XML format for
> reviews), perhaps because it's simply structured. I suspect where
> multiple vocabularies are needed then an external file may be more
> appropriate.

I think this is an excellent characterization Danny.

We do know that simple things like reviews work today (e.g. hReview).

We don't know where the limits are yet.  There may certainly be some.

We're ok with pushing forward with that understanding.

Microformats don't have to be infinitely flexible nor infinitely extensible.


>> A possible issue to address would be: should I provide OPML or XOXO?
> 
> I've a heuristic for that too : What is the data you wish to provide?
> For what purpose?

Excellent design questions.


> If the answer to either question is "Radio Userland"
> then the answer's OPML. Otherwise XOXO's probably a better bet.

Indeed.

As I said, with RSS, we are too late to avoid having to deal with another
XML format.

OPML is much more poorly specified, and much less adopted than RSS.  And it
is a much more obvious example of needless wheel reinvention.

Thus we have very good chance of seeing far more uptake of XOXO than OPML,
even in the short term.

Thanks,

Tantek