[microformats-discuss] microformats vs. plain XML formats

[Joshua Porter]

On Jul 13, 2005, at 8:08 AM, Tantek Çelik wrote:

> On 7/12/05 2:12 PM, "Joshua Porter" <porter at bokardo.com> wrote:
>
>
>> Is it fair to say that microformats are no further along in auto-
>> discovery than are standalone XML formats?
>>
>
> I'm not sure that "auto-discovery" as you use it means the same  
> thing as
> others use it to mean.  It is a bit of an overloaded term, and as  
> such, a
> specific use-case would help with understanding what you mean.

I'm talking about auto-discovery in the sense that Safari and Firefox  
autodiscover RSS feeds and provide additional functionality to them.  
(Danny and Ryan answered this question by saying that browsers don't  
*currently* autodiscover them in this way.)

>
>
>
>> 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.
>>
>
> Yes, microformats are built from XHTML building blocks, and thus  
> have all
> the support that those have, which is a level of support far above  
> "plain"
> XML.
>
> In addition, microformats can be added to web pages and still have  
> those web
> pages *validate*, something which is very important to modern web  
> designers.

Not important to users, however.

>
> "plain XML" on the other hand, cannot be added to an XHTML web page  
> and have
> it still validate, short of doing nasty things like CDATA/escaping the
> markup, or putting it into comments.  Both of which have already been
> covered for all the problems they have.

My RSS feed is full of CDATA escaping, and it works well. Assuming  
this is bad, though, could you provide a pointer to the coverage?

>
>
>
>> But that's not really doing
>> anything with the semantics we've added to our markup. (we might as
>> well be writing in any arbitrary format).
>>
>
> Not at all.  XHTML has numerous predefined semantics.  "plain XML"  
> has none
> (except perhaps the xml:lang attribute).

By this I mean that if UAs aren't doing anything with the semantic  
markup, it doesn't matter that it is semantic. It's like a book being  
optically scanned, as opposed to being *read*.

>
>
>
>> Taken further, it seems to me that for anything to be done with
>> microformats, our UAs will need to be updated in some fashion.
>>
>
> No.  *could be* updated, yes.
>
> *need to be* updated? No.  For example, tons have been done with  
> styling
> microformats with built-in CSS support, utilizing microformats with
> favelets/bookmarklets, Grease Monkey plugins etc.  None of which  
> required
> updating the browser.

I would consider bookmarklets and Grease Monkey scripts as updating  
the UA. (or at least the functionality of the UA). This is a good  
thing...that it is easy to add functionality relatively quickly.

>
> Similarly, you can subscribe to hCalendar in existing calendaring
> applications like Apple iCal and Mozilla Sunbird, without *any*  
> updates to
> those applications.
>
> This is one of the advantages of basing a microformat standard on well
> adopted other standards.  Instant interoperability.
>
>
>
>>  Of
>> course, Technorati is supporting some of them already....but we don't
>> want something that will be supported by only one vendor
>>
>
> Hence Technorati has from day 1 developed microformats as open  
> standards on
> an open wiki, open for anyone to view (and edit/contribute to).
>
> Note that this is in *stark* contrast to *numerous* other "standards"
> efforts which are typically developed either behind closed doors of a
> paid-membership only committee, or developed on a closed mailing  
> list, or a
> closed wiki, or perhaps just in the closed-mind of a singular blow- 
> hard
> individual.

I find a lot of resistance to Mr. Winer. As I'm new to this stuff,  
I'm not taking sides. I want the best technology, not an anti-person  
format.

>
>
>
>> ...and
>> presumably Technorati would support another XML format, too.
>>
>
> Not necessarily.  A big concern on the part of Technorati (and any  
> other
> search implementer) is data quality, signal to noise.  As such if  
> XML (like
> most) formats encourage invisible metadata, they will be of  
> significantly
> lower utility to Technorati than formats that simply markup already  
> visible
> data.

(presumably Technorati would consider supporting another widely- 
adopted XML format)

>
>
>
>> Thus, microformats, to me, sound like just as much work as would be a
>> separate format (like RSS).
>>
>
> What application / site are you looking at adding microformats too?

I've got several. My personal blog (bokardo.com). Various commercial  
sites...

>
>
>
>> Indeed, many of the microformats are
>> based on living formats written in plaintext or xml. So some are
>> already developed...like iCal,
>>
>
> Non-trivial to author.

It is after one person writes a Wordpress plugin, which takes about a  
day. Remember, only a tiny fraction of RSS feeds are written *by  
hand*...

>
>
>
>> xCal
>>
>
> Tried and failed already.  Effectively zero uptake on the Web.

I think you'll find that after the success of RSS that there will be  
a lot more interest on these types of things. Most the standards work  
was ahead of the curve, in my opinion, and didn't have the attention  
of the average developer (or Wordpress/MT junkie) to write plugins  
for it.

For example, I co-wrote an article on Digital Web this spring  
( http://www.digital-web.com/articles/ 
web_2_for_designers/) ...effectively years behind the initial  
thinking on these subjects, and it gets a lot of attention, not  
because its a *new* idea, but because it is *new to them*. I would  
assume that you've been ahead of the curve for many years. *Most*  
people are not, and are still authoring in ways that would make you  
squirm.

>
>
>
>> and OPML.
>>
>
> <sigh />
>
> A totally unnecessary reinvention of <ol><li><a href>.
>
> Those whose ignore standards are doomed to reinvent them.

Do you have the same opinion of RSS?

>
>
>
>> Therefore, I wonder if there are some applications for which a
>> separate format are better suited,
>>
>
> Perhaps non-web applications?
>
>
>
>> and presumably some applications
>> for which microformats are better suited.
>>
>
> Anything that involves publishing content on the Web.

I'm not sure I understand the "everything through XHTML" point of  
view. Why not embrace the paradigm similar to RSS (and possibly  
Google sitemaps) to have semantic formats at certain conventional  
locations? One possibility is that the index page of a site is going  
to turn into a *true* index page, with a bunch of <link> tags  
pointing to the formats available for discovery. Is this not desirable?

In the same way that we know where to find the root XHTML page, we  
(our UAs) know where to find the root RSS feed. The new Google  
sitemaps format, for example, is the same way.

>
>
>
>> 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*.
>>
>
> What do you develop Josh?  That will probably impact where you  
> spend your
> time.

I was talking, of course, about whether I should spend time updating  
my sites to microformats, or should I say, provide a .ics file  
instead of an hCalendar file (or should I provide both?).

This is a *big deal* for developers, to *change* the way that they do  
things (look at how many people are using table-based layouts). In  
the near future there will be too many formats to choose from (it  
could be that this is already happening).

>
>
>
>> A possible issue to address would be: should I provide OPML or XOXO?
>>
>
> If you are publishing on the web, XOXO.

:)

>
> If not, use whatever outline format is the most convenient  
> (cheapest to
> implement) for you and your actual use cases.
>
>
> Thanks,
>
> Tantek
>

Thanks,

josh