[uf-discuss] re: HTML5 support
Oli Studholme
microformats.org at boblet.net
Mon Jul 19 19:57:34 PDT 2010
Hey Scott,
On Tue, Jul 20, 2010 at 9:34 AM, Scott Reynen <scott at randomchaos.com> wrote:
>> Microdata doesn't go out of its way to be compatible with existing RDF vocabularies
>
> Maybe not specific vocabularies (that's kind of my point), but RDF itself is clearly a major consideration. There's a whole section on it:
>
> http://www.w3.org/TR/microdata/#rdf
No. There’s a sub-sub-section on converting to RDF, just as there are
for converting to JSON and Atom. That’s not a design goal, it’s
specified interoperability. There are also sub-sub-sections on vcard,
vevent and licensing vocabularies, so by the same logic these are also
major considerations (again no, they’re sample vocabularies).
> It's no surprise that general purpose formats like microdata don't express specific vocabularies as succinctly as microformats.
You’re not doing a lot of hCalendar formats I take it? ;-)
> I'd argue it is a bad idea in microdata, but not in microformats, because of the very distinction I'm trying to draw between the two.
As far as microdata goes it’s irrelevant — that’s something decided by
the *vocabulary* author. Adding it isn’t a bad idea if the vocabulary
author thinks the shortcut has more good than bad points.
> Making specific cases easier is the whole point of microformats, but it's not at all the point of microdata.
“Making specific cases easier is the whole point of the class
attribute, but it's not at all the point of microdata”
Microdata — and semantic class names plus posh coding patterns for
current microformats — are the method; a means to an end. Microdata
vocabularies use microdata to express semantics, just as microformats
use the class attribute etc to express semantics. Microformats are a
little more concise in general (cough, datetimes ;-) compared to the
same vocabulary in microdata (@class is shorter than @itemprop by 4
characters, @property is optional whereas @itemtype is required etc),
but the differences are not so great, and any class-based microformat
can be written using microdata.
peace - oli
PS @Philip the reasons for n optimisation are as in the wiki; a
combination of putting authors first (shortcut for western-style
“given-name family-name” names), and accommodating mistakes in the
original RFC. I guess there was the expectation that hCard would
mainly be used with western-style names, a lack of knowledge of
Vietnamese, Chinese and other names that would be incorrectly
classified by this optimisation, and/or this shortcut was valued above
i18n issues (it was made back in 2005 after all).
I’d originally thought of it as just an edge case in Japanese, but
reading about Vietnamese, Chinese and Korean names I’m starting to
feel this is a serious i18n issue. I wonder what Tantek’s view, and
the view of whoever else is working on hCard 1.0.1, is. I wonder if it
will be perceived to be as serious as the a11y issues the abbr time
pattern had…
Aah just found
http://microformats.org/wiki/hcard-issues-resolved#fn-opt-i18n
and it seems not. I guess there’s the assumption that east asian pages
specify their language, which seems somewhat disconnected from reality
:/
More information about the microformats-discuss
mailing list