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
[EMAIL PROTECTED]
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
