Hey Scott, On Tue, Jul 20, 2010 at 9:34 AM, Scott Reynen <sc...@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 :/ _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss