[uf-discuss] Microformats and RDFa not as far apart as previously thought
Manu Sporny
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
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
> 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
>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
> 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.
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
> <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.
--
Toby A Inkster
<mailto:ma...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
_______________________________________________
Guillaume Lebleu
> 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
> 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
> 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
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
>
> 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:
>
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
> 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>
>
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
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
> 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).
--
Toby A Inkster
<mailto:ma...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
_______________________________________________
Belov, Charles
> 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>
> 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
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
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
> 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
André Luís
>
> 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
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
attribute to a different, widely used date format that is both machine
and date friendly? Take the JS date format, for instance?
Dan Brickley
> 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
> 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
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
> 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
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
> 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
> 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
> 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
<mailto:ma...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
_______________________________________________
Toby A Inkster
> 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
> 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
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
> 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
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
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!