[uf-discuss] Format-of-Formats?

[Ryan King]

Joe,

First of all, I really appreciate your enthusiasm. I can see that you  
understand and appreciate microformats and the ideas behind them.

However, a format-for-formats is outside the scope of the discussion  
here. So, I'm going to have to ask that we take this discussion  
elsewhere. Other topics brought up in this thread (esp, later on,  
regarding evangelism and adoption) are definitely on-topic and  
important, but the technological topic of a meta-microformat is out  
of scope now (and possibly forever).

I'll explain with some inline comments (and hopefully convert this to  
an FAQ soon-ish)...

(if you have any questions/comments, remember, please take it off- 
list, feel free to email me directly about anything I say)

On Mar 30, 2006, at 3:01 PM, Joe Reger, Jr. wrote:
>> before having the arrogance to think they can do better.
>
> I'm not proposing that we create a replacement for XML Schema or any
> of the other great technologies out there... just that we agree on one
> as the "most frequently used, most standard, most common, baseline,
> generally accepted but not perfect" way to describe a microformat.

We can, its called prose.

Tantek's earlier point, which I agree with with, is this: Formats  
always need prose to describe them. Prose supersedes formal  
descriptions (mostly because, being our native representation as  
humans, its more reliable). Since this is the case, its is more  
useful and expedient to just do prose + examples (including reference  
implementations).

The second argument against meta-languages is history. Meta-languages  
have shown to be insufficient for describing formats in way that is  
fully interoperable with reality. Why should we believe that we're  
any smarter. *

> As you note, there are a lot of ways to crack this nut.  And this is
> the fact that I'm having trouble with.  Toolmakers, aggregators and
> innovators are having a tough time with microformats because each new
> one that pops up requires custom code.

It seems that you're suggesting that we can survive with writing a  
declarative description of a microformat, which can then produce code  
for publishing and consuming microformats.

I, personally, don't think this is a problem that has been solved  
anywhere and since it is outside the core technology needed for  
microformats adoption, it is extremely low priority.

> Instead of taking a leadership
> role, choosing one and advocating adoption, you seem to revel in the
> establishment of many microformats.  I'm questioning where the
> customization should be... at the user level where apps are
> differentiated?  Or at the format level?
>
> Why should each format have to start at ground zero,

I think this is an overstatement. Apps don't have to start at zero.  
There are many libraries for healing with  markup.

> write custom
> plugins, force users to install them and then gain adoption?  Why
> should Technorati have to write custom code at  the format level for
> each format

Because each one is different.

> ...
> Maybe we should see microformats.org as the high-end solution with the
> flexibility to cover everything. But I think we also need a
> microformats Light that enables most of the functionality that most of
> the people are looking for.

We already have 'microformats light,' its called 'semantic markup.'  
Semantic markup has been an option longer than microformats have.

> In the last 5 days I've seen these microformats proposed:
> Bookmark Exchange Format
> Attention Microformat
> Citation Format
> MicroId
> Plants Format
> Work of Art
> Conversation

3 of those formats already exist. The others are being worked on.

> Following this list you see these requests all the time.  This week's
> performance would predict 260 microformats in a year.  And really, if
> somebody's posting to this mailing list they're probably hyper-plugged
> in to geekland.  If we think about our users... the millions of people
> we rely on to make all of our geeky stuff actually useful... how many
> formats do you think are out there with pent-up demand?
>
> I'd say... um...  a lot.

I'd prefer not to think of requests in terms of numbers of formats,  
but in terms of functionality. With small, simple, modular  
microformats, many solutions are possible. We don't need a specific  
format for every use-case.

Also, more formats is not necessarily a good thing. Remember, we're  
working with a shared vocabulary, which means we need careful  
management of that vocabulary. We don't want to create another Tower  
of Babel.

> ...
> To me this user-oriented analysis paints an obvious argument for a
> format-of-formats.  The current microformat mailing list and developer
> community is doing great work but it's not supporting the users who
> want a quicker means of creating and using microformats.  I could be
> wrong on this... please prove me so.

I can understand that people want things quickly, but we can't just  
throw an idea in a microwave oven, hoping that it will come out tasty  
in a few minutes. The microformats process is much faster and  
efficient than a standards body, yet slower than two guys in a  
garage, which is more than ok– we're tackling hard problems.

> ...
>
> But before I go I'd like to ask everybody whether they agree with me
> in principle:  do you think that creating and using microformats
> should be easier for the average user?

They already are *easier*. Consider the other options for creating  
data formats: XML, RDF, etc.

> If so, do you think that a
> format-of-formats approach would be helpful wherein a user can simply
> define ten quick fields with XML, upload the file to their blog server
> and start blogging?

You can already use whatever semantics you want in your blog. No one  
is stopping you. However, when it comes to shared vocabularies, they  
must be, well, *shared*.

> Because there's nothing technically challenging about this proposal.
> As replies to my message have pointed out there are already numerous
> technologies that do this.  All we need to do is choose one and
> advocate toolmaker adoption/plugin development (movable type, live
> journal, drupal, etc).  Choosing and advocating is the issue here...
> not technology.  Something is better than nothing to fill this
> microformat long tail void.
>
> The ability for users to quickly define formats and use them to
> collaborate, meet, find and innovate is a critical next step.  I'd
> like to help it happen.  Here or elsewhere.  Hopefully here with the
> support of you, the people who actually understand this stuff.

If you have specific formats you'd like to work on, I'd be more than  
happy to help. I can't help with hypothetical formats, though.

>> I'm working on some extensions for
>> includes
>> (to transclude multiple XMDP profiles or portions thereof into a  
>> single
>> profile), but other than that, I consider XMDP "done".
>
> Interesting.  I'd enjoy looking at these.  Heck, maybe XMDP is exactly
> the sort of format-of-formats that I'm looking for.  If so, and if
> you're still actively developing it, why am I arrogant for asking
> whether something like it exists?

So, you're saying that you haven't looked at XMDP? You might want to  
check it out: http://gmpg.org/xmdp/.

>> The *one* exception that I know of to this that adherents have had  
>> (at
> least) some amount of success with is RDF.
>
> Ok, so that's another possible answer to my original question.  Yes,
> RDF is an option.  Again, why am I arrogant for asking about something
> that has had "some amount of success"?
>
> Sorry for the intrusion today.  Let me know if you're interested in
> working on a format-of-formats with me.  I've already received a
> number of kind private messages from people who say this is exactly
> what they're interested in seeing.

Please, before you create a new meta-format, consider all the prior  
art, especially XMDP.

-ryan

* As an interesting sidenote, in my personal experience, the only  
meta-languages (and I'm thinking meta-programming now) that I've  
found useful are meta-languages which operate on themselves.
--
Ryan King
ryan at technorati.com