[uf-discuss] Microformats and RDFa not as far apart as previously thought

2 views
Skip to first unread message

Manu Sporny

unread,
Jun 24, 2008, 12:03:30 PM6/24/08
to Microformats Discuss
There have been some interesting blog posts by people at the BBC,
Mozilla and W3C about Microformats and RDFa in the past two days. The
first covers BBC's decision to drop support for the abbr-based design
pattern written by Michael Smethurst (who worked with this community on
hAudio among other things):

Removing abbr-based Microformats from BBC
http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml

The second is a response from John Resig, of jQuery/Mozilla fame, here:

BBC Removing Microformat Support
http://ejohn.org/blog/bbc-removing-microformat-support/

The third is written by Mark Birbeck, who is the guy that proposed RDFa
several years ago and is the primary one behind the processing rules and
architecture for RDFa:

Microformats and RDFa are not as far apart as people think
http://internet-apps.blogspot.com/2008/06/microformats-and-rdfa-are-not-as-far.html

We've had discussions that parallel the ones above last summer:

http://microformats.org/discuss/mail/microformats-new/2007-July/000592.html
http://microformats.org/discuss/mail/microformats-discuss/2007-October/010850.html
http://microformats.org/discuss/mail/microformats-discuss/2007-October/010859.html
http://microformats.org/discuss/mail/microformats-discuss/2007-October/010879.html

I tend to agree with Edd Dumbill's post:

http://times.usefulinc.com/2008/06/24-uf-rdfa

Some are moving too quickly to dismiss both Microformats AND RDFa - the
two communities are cross-pollinating and there has been significant
lessons learned from both approaches. If you're going to blog about this
or discuss it - please don't fuel the Microformats vs. RDFa fire by
picking sides... it's detrimental to both communities.

Like Edd stated in his post, we have a bug that we need to fix (abbr
design pattern causing screen reader usability issues) and that has been
hanging over our heads for some time now. BBC's decision is a lesson
learned but is in no way some sort of sign that Microformats is on it's
way out.

Thoughts from the community? Anybody else blogging about this?

-- manu

--
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Blacksburg BarCamp 1.0
http://blog.digitalbazaar.com/2008/05/15/blacksburg-barcamp-10/

_______________________________________________
microformats-discuss mailing list
microforma...@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Frances Berriman

unread,
Jun 24, 2008, 12:20:19 PM6/24/08
to Microformats Discuss
On 24/06/2008, Manu Sporny <msp...@digitalbazaar.com> wrote:

Hey Manu,

Thanks for the links. I'm trying to keep track of all the
converastions popping up around this.

>
> Some are moving too quickly to dismiss both Microformats AND RDFa - the
> two communities are cross-pollinating and there has been significant
> lessons learned from both approaches. If you're going to blog about this
> or discuss it - please don't fuel the Microformats vs. RDFa fire by
> picking sides... it's detrimental to both communities.

Agreed. I'm so tired of this verses debate. This isn't a war where
anyone has to pick a side. They can work along side one another.

> Like Edd stated in his post, we have a bug that we need to fix (abbr
> design pattern causing screen reader usability issues) and that has been
> hanging over our heads for some time now. BBC's decision is a lesson
> learned but is in no way some sort of sign that Microformats is on it's
> way out.

I don't know if you saw, but the discussion is happening over on dev
[1] (mostly to get parser writer's feedback in the first instance) on
how to deal with the abbr. There's been work by Ben Ward on the
machine-data[2] options for a while now.

I agree, this is just *one* issue that we've failed to solve so far.

[1] http://microformats.org/discuss/mail/microformats-dev/2008-June/000552.html
[2] http://microformats.org/wiki/machine-data

--
Frances Berriman
http://fberriman.com

Toby A Inkster

unread,
Jun 24, 2008, 4:25:49 PM6/24/08
to microforma...@microformats.org
Manu Sporny wrote:

> Anybody else blogging about this?

I'm about half-way through writing an article on extending hCard with
RDFa. I'll ping this mailing list (and the RDFa one) when I'm done.

--
Toby A Inkster
<mailto:ma...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Belov, Charles

unread,
Jun 24, 2008, 5:48:22 PM6/24/08
to microforma...@microformats.org
>Message: 8
>Date: Tue, 24 Jun 2008 12:03:30 -0400
>From: Manu Sporny <msp...@digitalbazaar.com>
>Subject: [uf-discuss] Microformats and RDFa not as far apart as
> previously thought
>To: Microformats Discuss <microforma...@microformats.org>
>Message-ID: <48611AD2...@digitalbazaar.com>
>Content-Type: text/plain; charset=UTF-8

>There have been some interesting blog posts by people at the BBC,
>Mozilla and W3C about Microformats and RDFa in the past two days. The
>first covers BBC's decision to drop support for the abbr-based design
>pattern written by Michael Smethurst (who worked with this community on
>hAudio among other things):

>Removing abbr-based Microformats from BBC
>http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from
_bbc.shtml

I have come to a similar decision. In my case, I will split the
human-readable portion entirely from the microformat portion, and the
microformat portion will be entirely styled display:none.

That applies to machine-intermediated content. I feel it is
unreasonable to ask a non-technical person to produce ISO-format
dates/times, so microformats do not produce an acceptable solution at
this time for marking up meeting announcements.

Charles "Chas" Belov
SFMTA Webmaster
www.sfmta.com

Guillaume Lebleu

unread,
Jun 24, 2008, 6:17:24 PM6/24/08
to Microformats Discuss
Belov, Charles wrote:
> I feel it is unreasonable to ask a non-technical person to produce
> ISO-format dates/times, so microformats do not produce an acceptable
> solution at this time for marking up meeting announcements.
I agree that only an editor extension would make writing ISO-format
date/time practical by humans, which I never felt was compliant with
"designed for humans first, machine second".

What about the idea of a plain old English microformat ("POEM"?) based
on well-known practices in various languages [1], in the tradition of
"paving the cows path": these practices are pretty-well established IMO
and used by authors in the newspapers, magazines, etc. For instance, in
English:

<span class="dstart" lang="en-us">October 5, 2004</span>
<span class="dstart" lang="en-us">10/5/2004</span>
<span class="dstart" lang="fr">5 Octobre 2004</span>
<span class="dstart" lang="fr">5/10/2004</span>

The locale could be specified locally (lang="en-us") or inherited from
the HTML document or a containing div.

Granted it would make the parsing more complex, but it would comply with
"designed for humans first, machine second".

Also, additional class would be required to distinguish the date part
from the time part in something like:

<span class="dstart" lang="en-us"><span class="date">October 5,
2004<span> at <span class="time">6PM</span></span>

Just an idea,

Guillaume

[1] http://www.ego4u.com/en/cram-up/vocabulary/date/written

Toby A Inkster

unread,
Jun 24, 2008, 7:54:43 PM6/24/08
to microforma...@microformats.org
Guillaume Lebleu wrote:

> <span class="dstart" lang="en-us">October 5, 2004</span>


Cognition already supports this as a last ditch attempt at parsing
dates - but I wouldn't recommend it get adopted widely. It's too
unreliable; too much work to deal with internationalisation; too much
work full-stop in languages that don't provide a handy library that
takes care of most of the work.

_______________________________________________

Guillaume Lebleu

unread,
Jun 24, 2008, 11:08:50 PM6/24/08
to Microformats Discuss
Toby A Inkster wrote:
> Guillaume Lebleu wrote:
>
>> <span class="dstart" lang="en-us">October 5, 2004</span>
>
>
> Cognition already supports this as a last ditch attempt at parsing
> dates -

Thank you for the attempt.


> but I wouldn't recommend it get adopted widely. It's too unreliable;

Why is this that requiring that English content writers (I mean only
those don't want to use the abbr pattern) to write dates and times in
accordance to the existing precise rules of English grammar and
publishing style guides (ex. AP stylebook) they know about (or used to
know about) is less reliable than asking them to write them twice, one
in the format they like and a second time in an ISO format most of them
likely don't know about in an relatively arcane syntax?

I think it really depends on where our priorities are as a community. If
most hCalendar items are destined to be software-generated (including
via, say, a TinyMCE plugin) or are added by specialized staff, after the
content is authored, I agree with you. On the other hand, if we want
actual content authors to be able to add this mark-up, then I think
plain old English microformats may be more reliable, and actually more
used in the first place, than dark data or RDFa.


> too much work to deal with internationalisation;

I don't think we need to support all locales at once. I don't know in
how many written languages BBC publishes in, but it might be that
supporting en-uk and en-us might be enough for a start. Also, one can
imagine that Microformats tools could focus on the most common written
languages and then expose hooks for others to implement support for
other locales.


> too much work full-stop in languages that don't provide a handy
> library that takes care of most of the work.
>

True, but again, what are our priorities? making programmers' life
easier or making content authors and content readers' life easier?

Anyway, there are other problems. Just trying to think outside of the class.

Guillaume

Michael MD

unread,
Jun 25, 2008, 2:11:13 AM6/25/08
to Microformats Discuss

> Guillaume Lebleu wrote:
>
>> <span class="dstart" lang="en-us">October 5, 2004</span>
>
>
> Cognition already supports this as a last ditch attempt at parsing
> dates - but I wouldn't recommend it get adopted widely. It's too
> unreliable; too much work to deal with internationalisation; too much
> work full-stop in languages that don't provide a handy library that takes
> care of most of the work.
>

even in those that do there are too many ambiguities...

Even in rare cases where you might know what country something is in you
still can't be sure that date is written in a way that is common in that
country.

eg .. here in Australia dd/mm/yyyy is commonly used ... but I also see a
significant minority of sites in Australia using US-style mm/dd/yyyy because
it is the default setting in their CMS!

How would a parser be able to tell which part is the day and which is the
month? ....

... getting it wrong would be worse than not getting it at all!

of course the ideal long-term solution would be to teach people to write
dates more clearly (something like 12th June 2008 or July 8, 2008 is clear
enough
but the masses need to learn not to use those awful "slash" formats and
anything without the year or with 2 digit years)

until the use of ambiguous formats can be WIPED OUT we WILL need a version
for machines!

The former is of course unlikely to happen any time soon ... so machine
dates ARE needed .. without them you can say goodbye to hCalendar or
anything else that relies on dates!

George Brocklehurst

unread,
Jun 25, 2008, 5:23:58 AM6/25/08
to Microformats Discuss
On 24 Jun 2008, at 17:03, Manu Sporny wrote:

> Like Edd stated in his post, we have a bug that we need to fix (abbr
> design pattern causing screen reader usability issues) and that has
> been
> hanging over our heads for some time now. BBC's decision is a lesson
> learned but is in no way some sort of sign that Microformats is on
> it's
> way out.

Is it worth revisiting Tantek's original suggestion of using the
object element to represent dates? [1]

The idea was to do something like this:

<object data="20050125">January 25</object>

From what Tantek said on his blog, the main reason for not using
objects was that they were not well supported in Safari. However,
Safari's object support is now much improved: fallbacks are supported
and display:inline and intrinsic sizing will work correctly. Safari
2.0.2, which came out in November 2005, was the first version to
contain these improvements [2].

It might be that there are other reasons for not using <object> that
I've missed (I'm fairly new to the wonderful world of Microformats)
and it might be that there's still a significant population of Safari
users on 2.0.1 or older, but if not this could be a way forward that
gets around the <abbr> issue.

Just a thought,
G

[1] http://tantek.com/log/2005/01.html
[2] http://webkit.org/blog/32/webkit-fixes-in-safari-202-mac-os-x-1043/

Michael Smethurst

unread,
Jun 25, 2008, 5:28:04 AM6/25/08
to Microformats Discuss
Hello!

Apologies for not joining this thread earlier but my machine's been on the
flip.

Anyway, just wanted to say it was never my / our intention to fan the flames
of any uf vs rdfa skirmish.

I've posted a follow up note here:

http://www.bbc.co.uk/blogs/radiolabs/2008/06/microformats_and_rdfa_and_rdf.s
html

that hopefully gives a little more context.

To be double clear the issue at hand is about the accessibility of the
datetime abbreviation design pattern (although I suppose the geo microformat
would run into similar problems). It's still possible to use both hCalendar
and the abbreviation design pattern on bbc.co.uk. What's been banned is the
use of non-human-readable data in the title attribute of the abbreviation
element. We do realise that hCalendar can be used without the ADP - but in
this case none of the alternatives work for /programmes either.

On the ufs / rdfa front I'm sure the two can coexist peacefully. Without
wanting to drag myself any further into the mire and without wanting to
sound too much like an old hippy I'm also sure that the two communities
working together would benefit all.

So apologies for any consternation caused. Hope it all works out soon.

Michael


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Belov, Charles

unread,
Jun 26, 2008, 1:56:35 PM6/26/08
to microforma...@microformats.org
> -----Original Message-----
>
> Message: 2
> Date: Tue, 24 Jun 2008 15:17:24 -0700
> From: Guillaume Lebleu <guil...@lebleu.org>
> Subject: Re: [uf-discuss] RE: Microformats and RDFa not as far apart
> as previously thought
> To: Microformats Discuss <microforma...@microformats.org>
> Message-ID: <48617274...@lebleu.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed

>
> Belov, Charles wrote:
>> I feel it is unreasonable to ask a non-technical person to produce
>> ISO-format dates/times, so microformats do not produce an acceptable
>> solution at this time for marking up meeting announcements.
> I agree that only an editor extension would make writing ISO-format
date/time practical by humans, which I never felt was compliant with
"designed for humans first, machine second".
>
> What about the idea of a plain old English microformat ("POEM"?) based
on well-known practices in various languages [1], in the tradition of
"paving the cows path": these practices are pretty-well established IMO
and used by authors in the newspapers, magazines, etc. For instance, in
> English:
>
> <span class="dstart" lang="en-us">October 5, 2004</span> <span

class="dstart" lang="en-us">10/5/2004</span> <span class="dstart"
lang="fr">5 Octobre 2004</span> <span class="dstart"
lang="fr">5/10/2004</span>
>
> The locale could be specified locally (lang="en-us") or inherited from
the HTML document or a containing div.
>
> Granted it would make the parsing more complex, but it would comply
with "designed for humans first, machine second".
>
> Also, additional class would be required to distinguish the date part
from the time part in something like:
>
> <span class="dstart" lang="en-us"><span class="date">October 5,
2004<span> at <span
> class="time">6PM</span></span>

I'd suggest modifying that to not require the computer to parse the
date. Something like:
<span class="dstartm" lang="en-us">October</span> <span
class="dstartd">5</span>, <span class="dstarty">2004</span>

Hope this helps,


Charles "Chas" Belov
SFMTA Webmaster

Guillaume Lebleu

unread,
Jun 26, 2008, 2:16:19 PM6/26/08
to Microformats Discuss
Belov, Charles wrote:
> I'd suggest modifying that to not require the computer to parse the
> date. Something like:
> <span class="dstartm" lang="en-us">October</span> <span
> class="dstartd">5</span>, <span class="dstarty">2004</span>
>
+1: DRY-, POSH- and "humans first"-compatible IMO.

Maybe the following may be POSHer and backward-compatible with the
existing dstart class name convention?

<span class="dtstart" lang="en-us"><span class="month">October</span>
<span class="day">5</span>, <span class="year">2004</span></span>

Just a thought.

G

Martin McEvoy

unread,
Jun 27, 2008, 5:50:52 PM6/27/08
to Microformats Discuss
Hello Toby

On Tue, 2008-06-24 at 21:25 +0100, Toby A Inkster wrote:

> I'm about half-way through writing an article on extending hCard
> with
> RDFa

You might like to read this

http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html

and this

http://weborganics.co.uk/articles/show/extending-hcard-using-rdfa

may be relevant/helpful towards your article.


Martin

Toby A Inkster

unread,
Jun 27, 2008, 7:11:17 PM6/27/08
to microforma...@microformats.org
Martin McEvoy wrote:

> On Tue, 2008-06-24 at 21:25 +0100, Toby A Inkster wrote:
>
> > I'm about half-way through writing an article on extending hCard
> > with RDFa
>
> You might like to read this
> http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-
> in-microformats.html

Yep - if you take a look at the comments, you'll see I left one back
in March. ;-)

> and this
> http://weborganics.co.uk/articles/show/extending-hcard-using-rdfa

Yes - have read that too. The gist of mine is more about using RDFa
to add information to hCards in order to encapsulate information
which hCard itself can't represent (height, shoe size, whatever).

_______________________________________________

Belov, Charles

unread,
Jun 27, 2008, 7:41:27 PM6/27/08
to microforma...@microformats.org
>
> Message: 3
> Date: Thu, 26 Jun 2008 11:16:19 -0700

> From: Guillaume Lebleu <guil...@lebleu.org>
> Subject: Re: [uf-discuss] RE: Microformats and RDFa not as far apart
> as previously thought
> To: Microformats Discuss <microforma...@microformats.org>
> Message-ID: <4863DCF3...@lebleu.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed

>
> Belov, Charles wrote:
>> I'd suggest modifying that to not require the computer to parse the
>> date. Something like:
>> <span class="dstartm" lang="en-us">October</span> <span
>> class="dstartd">5</span>, <span class="dstarty">2004</span>
>>
> +1: DRY-, POSH- and "humans first"-compatible IMO.
>
> Maybe the following may be POSHer and backward-compatible with the
existing dstart class name convention?
>
> <span class="dtstart" lang="en-us"><span class="month">October</span>
<span class="day">5</span>, <span class="year">2004</span></span>
>

By George, I think you've got it!

Then there is the time issue, including 24-hour vs. 12-hour. So perhaps
(with all characters outside the inner spans being optional for human
readability):

<span class="dtstart" lang="en-us"><span class="month">October</span>

<span class="day">5</span>, <span class="year">2004</span>, <span
class="hhmm">1740</span> GMT<span class="tz">-7</span></span>

would be equivalent to:

<span class="dtstart" lang="en-us"><span class="month">October</span>

<span class="day">5</span>, <span class="year">2004</span>, <span
class="hhmmampm">5:40 a.m.</span> <span
class="tzabbr">PDT</span></span>

noting that hhmmampm might be expressed with or without the m, or with n
for noon (12n) or midnight (12m).

Hope this helps,
Charles "Chas" Belov
SFMTA Webmaster

_______________________________________________

Martin McEvoy

unread,
Jun 27, 2008, 8:33:51 PM6/27/08
to Microformats Discuss

On Sat, 2008-06-28 at 00:11 +0100, Toby A Inkster wrote:
> The gist of mine is more about using RDFa
> to add information to hCards in order to encapsulate information
> which hCard itself can't represent (height, shoe size, whatever).

Now that is an interesting idea, your article should make good reading.


Have fun

Martin

Fil

unread,
Jun 28, 2008, 7:07:09 AM6/28/08
to Microformats Discuss
I'm not a great fan of natural language here. What if I want to write
3l33t (well, not at my age mind you), or punk, maybe use Oktober
instead of October cause I'm a (admittedly bad) poet? The human will
understand, the computer won't.

-- Fil

Dan Brickley

unread,
Jun 28, 2008, 7:54:27 AM6/28/08
to Microformats Discuss
Fil wrote:
> I'm not a great fan of natural language here. What if I want to write
> 3l33t (well, not at my age mind you), or punk, maybe use Oktober
> instead of October cause I'm a (admittedly bad) poet? The human will
> understand, the computer won't.

Or Chinese?

Dan

--
http://danbri.org/

André Luís

unread,
Jun 28, 2008, 8:05:04 AM6/28/08
to Microformats Discuss
On Sat, Jun 28, 2008 at 1:33 AM, Martin McEvoy <in...@weborganics.co.uk> wrote:
>
> On Sat, 2008-06-28 at 00:11 +0100, Toby A Inkster wrote:
>> The gist of mine is more about using RDFa
>> to add information to hCards in order to encapsulate information
>> which hCard itself can't represent (height, shoe size, whatever).
>
> Now that is an interesting idea, your article should make good reading.
>

Indeed. Let me just ask this to see if we're on the same wave length
or if I misundertood something....

this extension would only work on xHTML, right? Or is it possible to
use rdfa in html? (I'm not that proficient in rdfa)

Cheers,
--
André Luís

André Luís

unread,
Jun 28, 2008, 8:03:13 AM6/28/08
to Microformats Discuss
Abbreviations are an issue as well. If we're trying to markup what
people actually publish, remember that not everyone will spell out the
month name:

October
Oct.

And other languages, like Portuguese:

Outubro
Out.

This, however, could be handled with <abbr>, without hindering accessibility.

<span class="month"><abbr title="October">Oct.</abbr></span>

No?

(sorry if this has been discussed. it's hard to keep up with all
discussions spanning over the mailing list and the IRC channel)
--
André Luís

Dimitri Glazkov

unread,
Jun 28, 2008, 8:16:21 AM6/28/08
to Microformats Discuss
Perhaps we could solve this by changing the value of the abbr title
attribute to a different, widely used date format that is both machine
and date friendly? Take the JS date format, for instance?

Dan Brickley

unread,
Jun 28, 2008, 9:16:06 AM6/28/08
to Microformats Discuss
Dimitri Glazkov wrote:
> Perhaps we could solve this by changing the value of the abbr title
> attribute to a different, widely used date format that is both machine
> and date friendly? Take the JS date format, for instance?

Not everyone uses the same calendar. For example there are lot of blogs
in Persian/Iranian/Farsi. See http://en.wikipedia.org/wiki/Iranian_Blog
... In these cases, often the machine format (notably Atom/RSS) will use
ISO-8601 and suchlike; while the human-facing text will often use a
'local' calendar. I don't have stats handy but I doubt this can be
dismissed as a corner-case.
http://en.wikipedia.org/wiki/Chinese_calendar#The_relevance_of_the_calendar_today
suggests this is also an issue in China.

cheers,

Benjamin Hawkes-Lewis

unread,
Jun 28, 2008, 10:33:55 AM6/28/08
to Microformats Discuss
André Luís wrote:
> this extension would only work on xHTML, right? Or is it possible to
> use rdfa in html? (I'm not that proficient in rdfa)

It's not possible to use RDFa in valid HTML and adding all the element
changes and new attributes necessary for RDFa to HTML is not part of the
current proposals for HTML5. If you want to to use RDF in an HTML
context, look to eRDF:

http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml

Note that some of the examples there misuse the TITLE attribute as badly
as some of the microformat patterns we've seen.

--
Benjamin Hawkes-Lewis

Ed Lucas

unread,
Jun 28, 2008, 12:03:52 PM6/28/08
to Microformats Discuss

George Brocklehurst wrote:
> Is it worth revisiting Tantek's original suggestion of using the
> object element to represent dates? [1]
>
> The idea was to do something like this:
>
> <object data="20050125">January 25</object>
>
> From what Tantek said on his blog, the main reason for not using
> objects was that they were not well supported in Safari. However,
> Safari's object support is now much improved: fallbacks are supported
> and display:inline and intrinsic sizing will work correctly. Safari
> 2.0.2, which came out in November 2005, was the first version to
> contain these improvements [2].
>
> It might be that there are other reasons for not using <object> that
> I've missed (I'm fairly new to the wonderful world of Microformats)
> and it might be that there's still a significant population of Safari
> users on 2.0.1 or older, but if not this could be a way forward that
> gets around the <abbr> issue.

I'm normally just a lurker here, but no-one has replied, so...

Using the object element seems like a very sensible solution. What are
the blocking issues now that Safari handles it? I've run a few quick
tests and Firefox,Opera, Safari and IE7 seem ok. IE6 won't display the
content, but that may be an issue with my copy of MultipleIE. According
to the Include-pattern page on the wiki (
http://microformats.org/wiki/include-pattern ) this may be due my to
ActiveX being disabled/broken.

The focus seems to have drifted toward smarter parsing of dates, but the
two nice things about the title="somethingmachinereadible" pattern were
that it could potentially be used for other data (not just dates), and
that it was simple enough for us muggles to understand and implement.

Any thoughts?
Ed

Ben Ward

unread,
Jun 28, 2008, 12:30:24 PM6/28/08
to andrel...@gmail.com, Microformats Discuss
On 28 Jun 2008, at 13:03, André Luís wrote:

> October
> Oct.
>
> And other languages, like Portuguese:
>
> Outubro
> Out.
>
> This, however, could be handled with <abbr>, without hindering
> accessibility.
>
> <span class="month"><abbr title="October">Oct.</abbr></span>

With the current abbr-pattern, your example should be:
<abbr class="month" title="October">Oct.</abbr>

That's a perfectly valid abbreviation, but doesn't address the
internationalisation issue.

<abbr class="month" title="October">Outubro</abbr> is not an
abbreviation, it's translation. We end up with the same problem that
exists in hcard with supporting <span class="tel">< span
class="type">cell</span>… in languages outside US English.

B

Ben Ward

unread,
Jun 28, 2008, 1:09:48 PM6/28/08
to Microformats Discuss

On 28 Jun 2008, at 17:03, Ed Lucas wrote:

> George Brocklehurst wrote:
>> Is it worth revisiting Tantek's original suggestion of using the
>> object element to represent dates? [1]
>>
>> The idea was to do something like this:
>>
>> <object data="20050125">January 25</object>

This particular example is invalid, as the data="" attribute must
contain a URI, and a URI cannot start with a number.

>> display:inline and intrinsic sizing will work correctly. Safari
>> 2.0.2, which came out in November 2005, was the first version to
>> contain these improvements [2].

For note, I don't feel that CSS support on an element should be of
consideration when designing microformats. We are operating at the
HTML level and must not produce techniques which depend on them
(although documenting techniques where CSS can be used to enhace/alter
microformats is still valuable, I'm simply meaning that HTML+CSS must
not ever be the primary solution to a problem).

>> It might be that there are other reasons for not using <object>
>> that I've missed (I'm fairly new to the wonderful world of
>> Microformats) and it might be that there's still a significant
>> population of Safari users on 2.0.1 or older, but if not this could
>> be a way forward that gets around the <abbr> issue.
> I'm normally just a lurker here, but no-one has replied, so...

> Using the object element seems like a very sensible solution. What
> are the blocking issues now that Safari handles it?

So, one solution I saw offered to the URIs-can't-start-with-numbers
issues was to do everything as a URL fragment, converting it to:

<object data="#20050125">January 25</object>

That, however, causes Safari 3 to render a box of the current page
within the OBJECT element, and so would introduce a CSS dependency to
keep it hidden. No good, I fear.

*However*, the following appears to be well behaved inline in Safari
2.04 and 3.1.1, Firefox 1, 1.5, 2 and 3, and Opera 7, 8 and 9.

<object class="dtstart" data="data://20080712"></object>

That uses the DATA URI scheme, which without a specified mime type and
charset, defaults to text/plain;chartset=US=ASCII. I think that would
be sufficient.

I've pastied my test case, and would be grateful if people could test
the behaviour in Internet Explorer: http://pastie.org/224023

Given that IE has a history of abysmal support for OBJECT and no
support for data: URIs… I have no idea what might happen.

See also:

http://en.wikipedia.org/wiki/Data:_URI_scheme
http://tools.ietf.org/html/rfc2397 (data: spec)
http://www.ietf.org/rfc/rfc2396.txt (URI spec)

B

Scott Reynen

unread,
Jun 28, 2008, 3:04:10 PM6/28/08
to Microformats Discuss
On [Jun 28], at [ Jun 28] 11:09 , Ben Ward wrote:

> On 28 Jun 2008, at 17:03, Ed Lucas wrote:
>
>> George Brocklehurst wrote:
>>> Is it worth revisiting Tantek's original suggestion of using the
>>> object element to represent dates? [1]
>>>
>>> The idea was to do something like this:
>>>
>>> <object data="20050125">January 25</object>
>
> This particular example is invalid, as the data="" attribute must
> contain a URI, and a URI cannot start with a number.

About a week ago I wrote:

> On the abbr-design-pattern page, markup rejections section [1] is
> the following text:
>
>> OBJECT with param value. (requires significant extra markup and CSS
>> in order to *behave* correctly)
>
> Can anyone provide more detail about this parenthetical rejection
> explanation?

If this problem has in fact been resolved (or at least improved) in
more recent browser versions, I suggest we look again at using
<object> and <param> together, e.g.:

<object class="dtstart"><param name="value" value="20050125" /
>January 25</object>

I expect using <param> will result in more readable and flexible
markup than data URIs.

Peace,
Scott

George Brocklehurst

unread,
Jun 28, 2008, 5:08:33 PM6/28/08
to Microformats Discuss
On 28 Jun 2008, at 18:09, Ben Ward wrote:

> I've pastied my test case, and would be grateful if people could
> test the behaviour in Internet Explorer: http://pastie.org/224023


IE 6, 7 and the beta version of IE 8 all visibly render the object
element as a small box, similar to the way they would render a missing
image: http://georgebrock.com/misc/object-in-ie.png

Toby A Inkster

unread,
Jun 28, 2008, 7:33:05 PM6/28/08
to microforma...@microformats.org
Ben Ward wrote:
> On 28 Jun 2008, at 17:03, Ed Lucas wrote:
>
> >> <object data="20050125">January 25</object>
>
> This particular example is invalid, as the data="" attribute must
> contain a URI, and a URI cannot start with a number.

It's perfectly valid. Absolute URIs can't start with a number, but
relative ones can - and the data attribute is permitted to contain
relative URIs.

This proposal is far less elegant than Frances' though.

_______________________________________________

Toby A Inkster

unread,
Jun 28, 2008, 7:51:46 PM6/28/08
to microforma...@microformats.org
André Luís wrote:

> this extension would only work on xHTML, right? Or is it possible to
> use rdfa in html? (I'm not that proficient in rdfa)

The RDFa people have only specifically defined RDFa in terms of
XHTML. This is for mostly pragmatic rather than ideological reasons -
it was far easier to spec out that way. In practice, it was always
expected that RDFa parsers would also support HTML, and indeed the
majority do.

There are two pitfalls with adding RDFa to HTML:

1. It adds a few new attributes, plus allows a handful of existing
attributes like 'rel', 'rev' and 'content' to be set on more elements
than before. Any non-trivial RDFa will make use of these facilities,
so can't be validated against the HTML 4.01 Strict DTD. It would
probably be not much more than 20 minutes work to download a copy of
the DTD, add these attributes in and get your HTML valid though.
(Some people seem to have an irrational dislike for custom DTDs, so
this solution may not be satisfactory to them.)

2. It also uses xmlns:X attributes, where X can be pretty much
anything. Because DTDs don't allow wildcard attributes to be defined,
you won't be able to create a DTD that can handle this. Again, use of
xmlns:X is not required by RDFa, but any non-trivial page will
probably need to. If you know that you're only going to be using a
limited number of RDF vocabs, your DTD can however define those ones
specifically (e.g. xmlns:dc for Dublin Core, xmlns:foaf for FOAF,
etc). But in the general case, this is less easy to get around.

Although, it is beyond the scope of the RDFa spec, so is not likely
to become official in the foreseeable future, I've proposed an
alternative syntax for the xmlns:X stuff to be used in HTML -
basically to use RFC 2731. (Which is what eRDF does.) I don't know
how many parsers have implemented it, but Cognition includes support
- http://buzzword.org.uk/cognition/

In short, if you're using the standard HTML 4.01 DTDs, RDFa will not
validate. But it will work.

Toby A Inkster

unread,
Jun 28, 2008, 8:24:38 PM6/28/08
to microforma...@microformats.org
Benjamin Hawkes-Lewis:

> If you want to to use RDF in an HTML context, look to eRDF

eRDF is an interesting experiment, but not particularly practical.

Probably the biggest practical problem with it is the use of the id
attribute to indicate that (by the attribute's mere presence) an
element is the subject of any data found in descendant elements. This
makes it difficult to add eRDF to existing documents which are
usually already sprinkled liberally with id attributes.

For example, if you have a side bar on a page and want to use it to
provide some supplementary information about the main body of text,
you might expect something like this to work:

<div id="sidebar">
<h2>About this page</h2>
<div class="dc-title">Foo bar</div>
<div class="dc-creator">Joe Bloggs</div>
</div>

However, this actually says that the title of <#sidebar> (i.e. not of
the whole page) is "Foo bar", and that <#sidebar> was created by Joe
Bloggs. Yes, you can rejig things a bit, make your sidebar use a
class instead of an id, but adding eRDF to existing pages a pain -
especially if they're not simple static pages, and you would need to
go through thousands of lines of server side code to find all those
id attributes.

If you're writing an eRDF page from the ground up, this will probably
not bother you as much.

The other serious concern is that any information you wish to state
about a resource which is not a physical anchor on the current page
needs to be made within a link. So if Alice wants to link to Bob's
page and mention the title of Bob's page, and when it was last
updated, she would need to write something along the lines of:

<a href="http://bob.example.net">
<span class="dc-creator">Bob</span>'s blog
<span class="dc-title">Groovin' with Bob</span>
was updated <span class="dc-date" title="20080629">today</span>
</a>

whereas without eRDF, most normal people would probably only want to
link the blog's title, not the whole phrase. This gets pretty awkward
if you want to say substantial amounts of information about an off-
page resource. (It's possible to work around it by using an id
attribute somewhere, saying the information about the id attribute
instead of saying it about the link, and then using owl:sameAs to say
that the link and the id attribute are the same thing. But that is a
hack.)

Final annoyance: varying between dots and hyphens to separate the
QName prefix and suffix, seemingly at random.

Yes, it's quite impressive what they managed to achieve, bringing
most of the RDF stack to HTML 4, without adding any new attributes or
elements. Yet when it comes to implementing it on real life pages,
it's annoying.

RDFa is a much nicer solution to work with.

Michael MD

unread,
Jun 28, 2008, 9:45:52 PM6/28/08
to Microformats Discuss
>The focus seems to have drifted toward smarter parsing of dates, but the


Sure ... splitting the date into day, month and year could be workable, or
somehow describing a date format in another element, if there is a standard
way to do it and it is easy to do, but I'm opposed to anything that relies
on unreliable heuristics or localisation to parse dates.

There are situations where markup clues used for localisation might be
misleading, such as people using microformats in a post on a site they do
not themselves run that may even be in a different country.
(a shared blogging site that allows html tags in posts would be a good
example here)

If a parser gets even 1% of dates wrong because of localisation errors it
could lead to a lot of people turning up to events on the wrong dates and
I'm sure those people would not be too happy about it.
So please lets not underestimate the importance of reliable date parsing!

It's already bad enough trying to cope with timezone issues in the real
world (eg people misusing 'Z' in their datetimes)

OK, maybe some aspects of ISO dates are not "human-friendly" enough and we
need to look at this, but dates do still need to marked up in a standard way
somehow!

There is also the issue of parsers becoming slow and bloated.

Yes I know its "humans first" but there are limits.

If people turn away from using a tool because it is unreliable or too slow
is it really "humans first" then?

Benjamin Hawkes-Lewis

unread,
Jun 29, 2008, 4:05:09 AM6/29/08
to Microformats Discuss
Michael MD wrote:
> There are situations where markup clues used for localisation might be
> misleading, such as people using microformats in a post on a site they do
> not themselves run that may even be in a different country.
> (a shared blogging site that allows html tags in posts would be a good
> example here)

Hmm. Couldn't the person or tool adding the microformat annotation also
add a lang attribute at the same time?

--
Benjamin Hawkes-Lewis

Karl Dubost

unread,
Jun 29, 2008, 11:16:43 PM6/29/08
to Microformats Discuss

Le 28 juin 2008 à 22:16, Dan Brickley a écrit :
> I don't have stats handy but I doubt this can be dismissed as a
> corner-case. http://en.wikipedia.org/wiki/Chinese_calendar#The_relevance_of_the_calendar_today
> suggests this is also an issue in China.

The imperial era calendar is used on many forms in Japan.


--
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool

Breton Slivka

unread,
Jun 30, 2008, 12:13:51 AM6/30/08
to Microformats Discuss
I think this sort of counter argument is a straw man. The proposal
from Guillaume was not to write a natural language parser that can
parse any kind of human written date. The proposal was to parse a very
specific and standardized format of date. If one were to write
"Oktober", the specified behavior for parsers should be to fail, and
possibly throw errors.

I for one, strongly agree with this approach. Essentially the problem
with the ABBR problem that the microformat community faces, is a set
of three restrictions, all applied, results in a set of 0 solutions.
Every solution I've seen so far only satisfies two of those
restrictions, and is immediately shot down by someone in the community
who thinks the third restriction is invoilatable.

the restrictions:

1. No information hiding
2. Humans first, machines second.
3. It must be in a format that's easily machine parsable.

You see the problem here? You guys are going to have to comprimise on
one of these three damned restrictions, or face irrelevance!

Breton Slivka

unread,
Jun 30, 2008, 12:22:33 AM6/30/08
to Microformats Discuss
> the restrictions:
>
> 1. No information hiding
> 2. Humans first, machines second.
> 3. It must be in a format that's easily machine parsable.
>
> You see the problem here? You guys are going to have to comprimise on
> one of these three damned restrictions, or face irrelevance!
>
>

To continue- the reason I strongly agree with Guillaume's proposal (go
back and read it, this time without attempting to distort it in order
to discredit it), is that it comprimises in the most ridiculous and
disingenuous of the three inviolable restrictions.

Dan Brickley

unread,
Jun 30, 2008, 3:54:59 AM6/30/08
to Microformats Discuss
Breton Slivka wrote:
> I think this sort of counter argument is a straw man. The proposal
> from Guillaume was not to write a natural language parser that can
> parse any kind of human written date. The proposal was to parse a very
> specific and standardized format of date. If one were to write
> "Oktober", the specified behavior for parsers should be to fail, and
> possibly throw errors.
>
> I for one, strongly agree with this approach. Essentially the problem
> with the ABBR problem that the microformat community faces, is a set
> of three restrictions, all applied, results in a set of 0 solutions.
> Every solution I've seen so far only satisfies two of those
> restrictions, and is immediately shot down by someone in the community
> who thinks the third restriction is invoilatable.
>
> the restrictions:
>
> 1. No information hiding
> 2. Humans first, machines second.
> 3. It must be in a format that's easily machine parsable.
>
> You see the problem here? You guys are going to have to comprimise on
> one of these three damned restrictions, or face irrelevance!

I suggests a 4th should be taken very seriously:

4. Respect the natural language, calendar, and writing system
preferences of the human content author.

cheers,

Dan

--
http://danbri.org/


Breton Slivka

unread,
Jun 30, 2008, 5:38:07 AM6/30/08
to Microformats Discuss

I thought that was implied by restriction #2, and thus leads to
proponents of restriction #3 getting in a hoot because perfectly
satisfying #2 is too hard.

so from there you can either comprimise #2 or #1 to satisfy proponents
of #3. violating #2 is a bad idea, but if you violate #1, Tantek steps
in and says you can't do that. Since it's difficult to overcome the
influence and authority of Tantek in this community, comprimising #3
is the only way you can go. Otherwise the argument is just going to go
around in circles forever.

Breton Slivka

unread,
Jun 30, 2008, 5:53:16 AM6/30/08
to Microformats Discuss
>>>
>>> the restrictions:
>>>
>>> 1. No information hiding
>>> 2. Humans first, machines second.
>>> 3. It must be in a format that's easily machine parsable.
>>>
>>> You see the problem here? You guys are going to have to comprimise on
>>> one of these three damned restrictions, or face irrelevance!
>>
>> I suggests a 4th should be taken very seriously:
>>
>> 4. Respect the natural language, calendar, and writing system preferences of
>> the human content author.
>>
>> cheers,
>>
>> Dan
>>
>
> I thought that was implied by restriction #2, and thus leads to
> proponents of restriction #3 getting in a hoot because perfectly
> satisfying #2 is too hard.
>
> so from there you can either comprimise #2 or #1 to satisfy proponents
> of #3. violating #2 is a bad idea, but if you violate #1, Tantek steps
> in and says you can't do that. Since it's difficult to overcome the
> influence and authority of Tantek in this community, comprimising #3
> is the only way you can go. Otherwise the argument is just going to go
> around in circles forever.
>

But really, when you get right down to it, in this community there is
at least one, strongly influential person who is a proponent of each
of the three restrictions, and you're never going to make all three of
them perfectly happy. I'm vastly simplifying the case here, but I
think that's basically why the community hasn't cracked this nut yet.
It's a "wicked problem". Any solution is going to be some kind of
comprimise, and there's going to be someone in the community quite
passionately against it, so we're basically paralyzed until we can all
decide which of the three "rules" is not sacred.

Michael MD

unread,
Jun 30, 2008, 5:56:30 AM6/30/08
to Microformats Discuss
> 4. Respect the natural language, calendar, and writing system preferences
> of the human content author.
>

The ONLY way I can see to do that without compromising on reliability or
speed would be to actually fully describe the date format in the markup in
the page itself.

Ben Ward

unread,
Jun 30, 2008, 1:11:20 PM6/30/08
to Microformats Discuss
I'd like to make a very important point.

On 30 Jun 2008, at 10:38, Breton Slivka wrote:

> if you violate #1, Tantek steps
> in and says you can't do that. Since it's difficult to overcome the
> influence and authority of Tantek in this community, comprimising #3
> is the only way you can go. Otherwise the argument is just going to go
> around in circles forever.

To quote the wiki:

“Microformats are not controlled by any individual or organization”
http://microformats.org/wiki/microformats#microformats_are_not

Disagreement within community members is always likely, such is the
nature of community. At this point in this community's life, no one
person is more important than another, and if that were ever to be the
case, the community and the effort of microformats generally will
suffer greatly.

When someone says you ‘can't’ do something, it's likely in the context
of the microformats principals. Someone saying ‘no’ cannot be backed
up only by their reputation and stature. ‘Citation needed’, is perhaps
the most succinct requirement.

The most worrying thing about this message is that anyone should
perceive the direction of this community as being dictated by one
personality's viewpoint. That is not the case, and the microformats
effort will fall apart if it ever was. To make decisions pre-emptively
out of this misperception is not going to lead us to the best solutions.

Additionally, it may well be that we're dealing with a problem right
now calls for an exception to a principal. I'm not aware that we've
ever consciously made exceptions before, so there's no precedent. As
such, the justification for and the scope of such exception needs to
be _very clearly documented_ and approached thoroughly. The
justification for making an exception needs to be held to very careful
scrutiny.

B

Sarven Capadisli

unread,
Jun 30, 2008, 5:11:01 PM6/30/08
to Microformats Discuss
On Wed, Jun 25, 2008 at 5:23 AM, George Brocklehurst
<george.br...@gmail.com> wrote:
> Is it worth revisiting Tantek's original suggestion of using the object
> element to represent dates? [1]
>
> The idea was to do something like this:
>
> <object data="20050125">January 25</object>
>
> From what Tantek said on his blog, the main reason for not using objects was
> that they were not well supported in Safari. However, Safari's object
> support is now much improved: fallbacks are supported and display:inline and

> intrinsic sizing will work correctly. Safari 2.0.2, which came out in
> November 2005, was the first version to contain these improvements [2].

1. The purpose of the <object> element is to allow the browser to run
an external application for a non-native data type (e.g., Java applet)
[1].
2. Safari 3 is actually handling <object> the corect way. [2]

<object> is not the right way to go in this case.

[1] http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3
[2] http://microformats.org/wiki/include-pattern-feedback#Objects_and_Browser_Behavior
(see point: Sarven Capadisli 16:34, 23 Jun 2008 (PDT))

Breton Slivka

unread,
Jun 30, 2008, 7:49:41 PM6/30/08
to Microformats Discuss


Yes, I know that's the party line, but vehemantly insisting on the
truth of such an assertion does not make it true. Are you seriously
suggesting that there are cases where someone has proposed a solution
involving information hiding, and Tantek HASN'T stepped in, and
immediately put an end to all conversation along those lines? If there
is such a case, I'm quite curious to see it, and I'm also quite
curious to see what else must have stepped in the way to put an end to
that line of solutions.

Yes, restriction #1, "no information hiding" is a "microformats
community principle", but it's quite obviously Tantek's baby, and in
the past, it's primarily been Tantek who has enforced that rule, and
Tantek's enforcement has been effective. If this reality disrupts your
rose colored idealistic view of the microformats community, well, I
can't help you. You haven't stated a particularly compelling case.
You've only recited community dogma.


That said, I actually agree with the rule, and I'm glad it's being
enforced, and I don't mind that it happens to be Tantek that's
enforcing it. It's a good rule, and I understand the reasoning behind
it. All I'm saying is that if we're not going to hide information, and
we're not going to make things difficult for humans reading the
microformat, or humans writing the microformat, violating restriction
#3 is the *ONLY* way to go, until someone happens to pull a magic
bullet out of the air. But I'm honestly not holding out hope. If
nobody wants to violate Rule #1, and nobody wants to violate Rule #2,
we're going to have to make bulkier more complicated parsers.

Breton Slivka

unread,
Jun 30, 2008, 7:59:52 PM6/30/08
to Microformats Discuss


Also, I would like to point out, that the restrictions I've listed are
not binary. All the solutions I've seen fall somewhere along a
continuum, and indeed many existing microformats violate some
principle or another to some extent. The ABBR pattern at the center of
this debate violates restriction #1 and restriction #2 to some extent.
It's semi hidden data that is semi unfriendly to humans. And it's the
truth and value of the restrictions #1 and #2, I think, that have led
to the failure of the ABBR pattern- It failed because of those
violations. And it's especially those failures in restriction #1, and
#2 that I think will force a solution that must violate the implicit
community "rule" of avoiding complicated parsers.

Reply all
Reply to author
Forward
0 new messages