@Ben Ward: It has previously been stated that that list is incomplete. Are you now saying that that is not the case?

If the admins do not act in secret, where are the archives of their mailing list available?

I’m not aware that anyone has claimed that that mailing list is being used for the development of microformats; that’s a straw-man. But it is, is it not, used to determine the rules by which the microformats “community” wiki, mailing list and IRC channel are governed? And discussion of those methods of governance are prohibited on those fora, is it not?.

As for “calling” people on their acting inappropriately, I asked, over a year ago, what was happening to the money paid for the T-shirts sold via the microformats wiki:

http://microformats.org/discuss/mail/microformats-discuss/2007-June/009902.html

As yet, no-one has answered me. Complaints about the actions of some of the admins on the list you cite has also been loudly ignored (or “not ignored, just not answered”, as one of them once defended similar such aloofness.).

I’d gladly “throw stones”, as you choose to describe making legitimate criticism, from inside the community, rather than outside it. But that’s not allowed either, is it?

You have my e-mail address; I’m quite happy to discuss this with you 1-1.

The list of community admins at microformats.org is clearly documented here: http://microformats.org/about/people/ — comments suggesting that this group operates in secret are entirely false.

We do have a microformats-admin mailing list. It is never, ever used for the development of microformats. I’ll happily tell you the last active thread there concerned last month’s upgrade of the microformats.org blog to WordPress 2.5, and asked whether we wanted to switch categories to tags for our posts there.

I emphasise as well that this group are community admins, not the ‘owners’ of microformats. It happens, of course, that those who are prepared to put in the time to help admin the community are also people who have time to put into developing microformats as well.

If you ever feel that any individual within the community — admin or otherwise — is acting inappropriately, bypassing the process or ignoring the work of others in favour of their own preferred solution regardless of merit, you should call them on it. That, ultimately, is how a community has to work. Throwing stones in blog comments from outside doesn’t really help the situation (for one, you can’t rely on them being noticed). I refer, of course, only to the stone throwing comments.

Work on this issue has been sporadic; it’s a volunteer community, after all. Not that I’m saying to huge timescale of non-resolution is in any way acceptable (it isn’t, in my view, I’m just trying to give some take on why). Currently things are moving quite well, with a number of different tracks approaching the core issues. See:

• machine-data
• datetime-design-pattern#other_proposals

Additionally, the invisible supplementary data pattern mentioned in this post is just one proposed solution (within the limits of valid HTML4), hence the lack of parser support. The wiki page in question emphasises that it shouldn’t be used in publishing yet. The open issues for that pattern are now wrapped up in the value-excerption-pattern-issues documentation.

Thanks,

Ben (on that list of microformats admins)

I don’t mean to come out defending anyone, but the abbr-design-pattern and the datetime-design-pattern are two different things.

I can use an abbr to specify a certain property of a microformat without hindering accessibility. Abbreviating a name [abbr title="André Luís"]André[/abbr], for example.

The problem lies in the datetime, like he said on the line after that… we can all agree on that.

A similar pattern is used for publication dates in hAtom and hAudio.

The latter also uses this gem of a pattern for the duration of mp3 files and the like (referring in this example from the hAudio spec on the microformat wiki to 5 minutes and 48 seconds):

[abbr class="duration" title="PT5M48S"]5:48[/abbr]

Abbr wasn’t picked on a whim. Yes semantics are questionable, but it fits well given we’re working with html, just as we ‘abuse’ definition lists. Jeremy has already pointed out that the title attribute was a good fit. As for screen readers, comment can only be made from testing. Is it really a showstopper?

Also, an aim was to be machine readable; to provide a standard we could work off, and it succeeded.